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

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

Info

Publication number
CN116318677A
CN116318677A CN202310305681.1A CN202310305681A CN116318677A CN 116318677 A CN116318677 A CN 116318677A CN 202310305681 A CN202310305681 A CN 202310305681A CN 116318677 A CN116318677 A CN 116318677A
Authority
CN
China
Prior art keywords
server
client
key
message
public key
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
CN202310305681.1A
Other languages
English (en)
Inventor
尹康凯
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangdong Oppo Mobile Telecommunications Corp Ltd
Original Assignee
Guangdong Oppo Mobile Telecommunications Corp Ltd
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 Guangdong Oppo Mobile Telecommunications Corp Ltd filed Critical Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority to CN202310305681.1A priority Critical patent/CN116318677A/zh
Publication of CN116318677A publication Critical patent/CN116318677A/zh
Pending legal-status Critical Current

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]

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
Figure BDA0004146781060000151
Figure BDA0004146781060000161
在不同的阶段，所述客户端和服务端端发送和/或接收的数据，使用不同的密钥进行加密、解密。当握手完成后，进入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 BDA0004146781060000162
其中，所述客户端和或服务端在接收到告警消息的情况下，必须断开连接。
在一些实施例中，Payload内容为Handshake的情况下，Handshake消息的代码包括：
Figure BDA0004146781060000163
Figure BDA0004146781060000171
在一些实施例中，所述Handshake用于发送握手消息，所述握手消息包括：第一信息、第二序列、第一校验数据、第一验证信息、第二校验数据、第二验证信息、第三序列、第一重传请求、第一问候信息中至少一种。
在一些实施例中，至少一个Handshake消息的Epoch相同，则发送所述至少一个Handshake消息的一端可以将所述至少一个Handshake消息合并，如此只需要加密一次。
相应地，在接收所述消息的一端解密数据时，通过Handshake.len确定每个Handshake消息的边界，通过整条消息长度确定一条消息中包含的所有Handshake。
图14中，客户端发送的ClientHello的代码包括：
Figure BDA0004146781060000172
其中，random包括8字节的随机数据，用于防止重放攻击。extension为扩展，用于描述所述客户端的自身能力和相关参数。Extension中所有扩展必须按照扩展类型从小到大的顺序排列。
ClientHello是协议协商的第一条消息，由Client向Server发送。用于向Server告知所述Client的认证能力以及自定义参数。
图14中，服务端发送的ServerHello的代码包括：
Figure BDA0004146781060000173
其中，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 BDA0004146781060000174
其中，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的配网协议中传输ECJPAKERound 1数据包括步骤S401至步骤S402，此处不再重复赘述。
图14中，Authenticate消息的代码包括：
Figure BDA0004146781060000181
其中，所述Authenticate消息用于传输认证数据。消息格式会根据cipher_suites定义的Authentication列的取值变化。特殊的，当Authentication取值为None时,该消息必须被省略。不同的认证方式下,Authenticate构造方式不同。
在认证方式使用ECDH的配网协议的情况下，Authenticate消息的代码包括：
Figure BDA0004146781060000182
其中，所述Authenticate消息用于对ECDH的证书认证，支持两种证书：X509证书与自定义证书。
图14中，Finished消息的代码包括：
Figure BDA0004146781060000183
其中，verify_data为使用当前Transcripthash值计算HMAC。计算方法包括：
Figure BDA0004146781060000184
其中，TranscriptHash：Server：TranscriptHash(ClientHello1……ServerAuthenticate)。
Client：TranscriptHash(ClientHello1…Server Authenticate,ServerFinished,Client Authenticate)。
Finished Key:Server:Expand(PRK＝ServerHandshakeTraffic,|abe|＝”htbtsfinished”,len＝Hash Length)。
Client:Expand(PRK＝ClientHandshakeTraffic,|abe|＝”htbts finished”,len＝Hash Length)
图14中，Application Data消息的Content部分为完整的用户数据。
所述消息代码中，extension是对消息的补充说明，代码包括：
Figure BDA0004146781060000185
其中，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 BDA0004146781060000191
其中，supported_version指示所述客户端或服务端支持的协议版本。目前协议版本为1。
supported_version必须被添加到ClientHello、ServerHello、HelloRetryRequest中。并填写一个Version。Server填写的Version将作为本次连接的协议版本。
在一些实施例中，当Client在收到的ServerHello中，发现supported_version扩展中存在多个Version或发现Version自己不支持时，clent应该发送protocol_version警告并关闭连接。
图14中，cipher_suites的代码包括：
Figure BDA0004146781060000192
其中，所述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 BDA0004146781060000193
在一些实施例中，支持的EC曲线参数。定义如表4：
表4
NamedGroup sym
0x17 secp256r1
0x18 secp384r1
0x19 secp521r1
0x1D x25519
其中，Client在ClientHello中填写一个或多个自己支持的NamedGroup，但Server在ServerHello和HelloRetryRequest中，选中并填写一个NamedGroup。Server填写的NamedGroup将作为本次连接使用的EC曲线。
在一些实施例中，当Client在收到的ServerHello中，发现supported_group扩展中存在多个NamedGroup或发现NamedGroup自己不支持时，Client应该发送unexpected_message警告并关闭连接。
图14中，key_share的代码包括：
Figure BDA0004146781060000194
其中，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 BDA0004146781060000201
在一些实施例中，如果不确定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 TransportLayer(TLS)Section 7.2.217中定义相同。对应ClientHello/ServerHello中的“ECJPAKEKeyKPPairList”扩展。identtity字段被删除，使用mbedTLS实现中预定义的“Client”/“Server”。
图14中，ecjpake_key_kp_params的代码包括：
Figure BDA0004146781060000202
其中，格式定义与Elliptic Curve J-PAKE Cipher for Transport Layer(TLS)Section 7.318中定义相同。对应ServerKeyExchange/ClientKeyExchange中的“ServerECJPAKEParams”或“ClientECJPAKEParams”。
在一些实施例中，所述“ecjpake_key_kp_params”用于指示ECJPAKE的协议中的公钥，如第五公钥、第六公钥等。
图14中，TrainscriptHash是握手过程中需要保持的Hash上下文，用于保障握手过程数据的完整性。Client、Server每发送、接收一条消息，都需要将消息内容写入Hash上下文。Client在收到ServerHello或HelloRetryRequest时初始化TranscriptHash。Server在收到第一包ClientHello时初始化TranscriptHash。
在一些实施例中，TranscriptHash构造方法包括：
Figure BDA0004146781060000203
其中，HelloRetryRequest一般情况下是不需要使用的，这样整个交互过程就会省略HelloRetryRequest和第二个ClientHello。
此时TranscriptHash组成包括：
Figure BDA0004146781060000204
在一些实施例中，消息序号的代码包括：
Figure BDA0004146781060000205
其中，消息序号分为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算法生成服务端共享密钥，客户端通过服务端发送消息中的第一公钥字段(如keyshare字段)的服务端的第一公钥基于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，ErasableProgrammable Read-Only Memory)、电可擦除可编程只读存储器(EEPROM，ElectricallyErasable Programmable Read-Only Memory)、磁性随机存取存储器(FRAM，ferromagneticrandom access memory)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(CD-ROM，Compact Disc Read-Only Memory)；磁表面存储器可以是磁盘存储器或磁带存储器。易失性存储器可以是随机存取存储器(RAM，Random Access Memory)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(SRAM，Static Random Access Memory)、同步静态随机存取存储器(SSRAM，SynchronousStatic Random Access Memory)、动态随机存取存储器(DRAM，Dynamic Random AccessMemory)、同步动态随机存取存储器(SDRAM，Synchronous Dynamic Random AccessMemory)、双倍数据速率同步动态随机存取存储器(DDRSDRAM，Double Data RateSynchronous 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 LogicDevice)、FPGA、通用处理器、控制器、MCU、MPU、或其他电子元件实现，用于执行前述方法。
本申请实施例还提供了一种存储介质，用于存储计算机程序。
可选的，该存储介质可应用于本申请实施例中的第一客户端，并且该计算机程序使得计算机执行本申请实施例的各个方法中的相应流程，为了简洁，在此不再赘述。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
以上所述，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围，凡在本申请的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本申请的保护范围之内。

Claims (18)

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

Priority Applications (1)

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

Applications Claiming Priority (2)

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

Related Parent Applications (1)

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

Publications (1)

Publication Number Publication Date
CN116318677A true CN116318677A (zh) 2023-06-23

Family

ID=80352647

Family Applications (2)

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

Family Applications Before (1)

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

Country Status (4)

Country Link
US (1) US20230171090A1 (zh)
EP (1) EP4170962A4 (zh)
CN (2) CN114124368B (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

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101459506B (zh) * 2007-12-14 2011-09-14 华为技术有限公司 密钥协商方法、用于密钥协商的系统、客户端及服务器
CN101488853B (zh) * 2009-01-15 2011-04-13 赵建国 一种基于种子密钥管理的交叉认证方法
CN102447690B (zh) * 2010-10-12 2015-04-01 中兴通讯股份有限公司 一种密钥管理方法与网络设备
CN104618903A (zh) * 2013-11-04 2015-05-13 华为技术有限公司 密钥协商处理方法和装置
US9973481B1 (en) * 2015-06-16 2018-05-15 Amazon Technologies, Inc. Envelope-based encryption method
CN106470104B (zh) * 2015-08-20 2020-02-07 阿里巴巴集团控股有限公司 用于生成共享密钥的方法、装置、终端设备及系统
WO2017152423A1 (zh) * 2016-03-11 2017-09-14 华为技术有限公司 密钥协商方法、设备和系统
CN106411528B (zh) * 2016-10-17 2019-06-14 重庆邮电大学 一种基于隐式证书的轻量级认证密钥协商方法
WO2018177905A1 (en) * 2017-03-29 2018-10-04 Koninklijke Philips N.V. Hybrid key exchange
EP3402118A1 (en) * 2017-05-10 2018-11-14 Koninklijke Philips N.V. Key agreement devices and method

Also Published As

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

Similar Documents

Publication Publication Date Title
CN108650227B (zh) 基于数据报安全传输协议的握手方法及系统
EP3493502B1 (en) Supplying an iot-device with an authentication key
EP1748594B1 (en) Method for realizing transmission of syncml synchronous data
EP3272094B1 (en) End-to-end authentication at the service layer using public keying mechanisms
EP3044984B1 (en) Communicating with a machine to machine device
US8583809B2 (en) Destroying a secure session maintained by a server on behalf of a connection owner
KR20190020140A (ko) 이종 네트워크들에 대한 통합 인증
US20230171090A1 (en) Data Transmission Method, And Electronic Device
US20220353060A1 (en) Handling of machine-to-machine secure sessions
US20210165885A1 (en) Extended Authentication Method And Apparatus For Generic Bootstrapping Architecture, And Storage Medium
CN108040071A (zh) 一种VoIP音视频加密密钥动态切换方法
US11949781B2 (en) Data transmission method, device, apparatus and storage medium
CN116321158A (zh) 基于证书的本地ue认证
EP4322459A1 (en) Improved security establishment methods and systems
EP4322454A1 (en) Improved security establishment methods and systems
EP4322463A1 (en) Improved security establishment methods and systems
EP4322460A1 (en) Reliability setting for improved security establishment methods and systems
EP4322462A1 (en) Improved security establishment methods and systems wherein keys are derived from a protocol transcript
EP4322461A1 (en) Improved security establishment methods and systems
EP4322455A1 (en) Improved security establishment methods and systems
EP4322472A1 (en) Improved security establishment methods and systems
EP4322456A1 (en) Quantum secure implicit authenticated password-based protocols and systems
EP4322457A1 (en) Improved security establishment methods and systems
WO2024033256A1 (en) Improved security establishment methods and systems

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination