CN117062032A

CN117062032A - Binding method and device of Bluetooth device, communication method and device, electronic device and medium

Info

Publication number: CN117062032A
Application number: CN202310929694.6A
Authority: CN
Inventors: 李政; 夏勇峰
Original assignee: Beijing Beehive Century Technology Co ltd
Current assignee: Beijing Beehive Century Technology Co ltd
Priority date: 2023-07-27
Filing date: 2023-07-27
Publication date: 2023-11-14

Abstract

The embodiment of the application provides a binding method, a communication method, a device, electronic equipment and a medium of Bluetooth equipment, wherein the Bluetooth equipment is communicated with a service end through an application end, and the application end is carried on terminal equipment; the method comprises the following steps: transmitting the equipment information of the home terminal to a server terminal; obtaining first key data based on a key negotiation mechanism; verifying the validity of the first key data and the second key data; the second key data is obtained by the server end based on a key negotiation mechanism; the first key data and the second key data are used for the Bluetooth equipment to carry out encrypted communication with the application terminal; in response to receiving the confirmation information, confirming that the Bluetooth equipment is successfully bound with the user identifier of the application terminal; the confirmation information is sent after the equipment information, the user identification and the second key data are bound by the server based on validity verification.

Description

Binding method and device of Bluetooth device, communication method and device, electronic device and medium

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method for binding bluetooth devices, a communication method, a device, an electronic device, and a medium.

Background

At present, communication is often performed between a bluetooth device and a terminal device through a short-distance communication mode such as BLE (Bluetooth Low Energy ). The terminal device can install bluetooth APP, and the user can use bluetooth device's more functions through APP. However, since BLE is a channel between bluetooth device and terminal device, when a user changes a terminal device and logs in APP, or when a user logs in APP using the same account number at a different terminal device, a new terminal device or each different terminal device needs to be bluetooth paired and bound with bluetooth device, respectively. This obviously brings great inconvenience to the user.

Disclosure of Invention

The embodiment of the application aims to provide a binding method, a communication method, a device, electronic equipment and a medium for Bluetooth equipment, which are used for realizing the technical effect that different terminal equipment does not need to be bound with the Bluetooth equipment again after logging in an APP.

The first aspect of the embodiment of the application provides a binding method of Bluetooth equipment, which is applied to the Bluetooth equipment, wherein the Bluetooth equipment communicates with a server through an application end, and the application end is carried on terminal equipment; the method comprises the following steps:

Transmitting the equipment information of the home terminal to the server terminal;

obtaining first key data based on a key negotiation mechanism;

verifying the validity of the first key data and the second key data; the second key data is obtained by the server based on the key negotiation mechanism; the first key data and the second key data are used for the Bluetooth equipment to carry out encrypted communication with the application end;

in response to receiving the confirmation information, confirming that the Bluetooth equipment is successfully bound with the user identifier of the application terminal; and the confirmation information is sent after the equipment information, the user identification and the second key data are bound by the server based on the validity verification.

The second aspect of the embodiment of the application provides a binding method of Bluetooth equipment, which is applied to a server, wherein the server communicates with the Bluetooth equipment through an application end, and the application end is carried on terminal equipment; the method comprises the following steps:

acquiring equipment information of the Bluetooth equipment and a user identifier sent by the application terminal;

obtaining second key data based on a key negotiation mechanism;

binding the equipment information, the user identification and the second key data to obtain a mapping relation in response to determining that the first key data and the second key data are effective; wherein the first key data is obtained by the Bluetooth device based on the key negotiation mechanism; the first key data and the second key data are used for the Bluetooth equipment to carry out encrypted communication with the application end;

And returning confirmation information to the Bluetooth equipment.

The third aspect of the embodiment of the application provides a Bluetooth communication method, which is applied to an application end carried on terminal equipment, wherein the application end communicates with a server end; the method comprises the following steps:

acquiring second key data obtained by the server based on a key negotiation mechanism;

encrypting communication with the Bluetooth device at a Bluetooth application layer based on the first key data and the second key data;

wherein the first key data is obtained by the Bluetooth device based on a key negotiation mechanism.

The fourth aspect of the embodiment of the application provides a binding device which is applied to the Bluetooth equipment, wherein the Bluetooth equipment communicates with a server through an application end, and the application end is carried on terminal equipment; the device comprises:

the first sending module is used for sending the equipment information of the home terminal to the server terminal;

the first key module is used for obtaining first key data based on a key negotiation mechanism;

the first verification module is used for verifying the validity of the first key data and the second key data; the second key data is obtained by the server based on the key negotiation mechanism; the first key data and the second key data are used for the Bluetooth equipment to carry out encrypted communication with the application end;

The first confirmation module is used for responding to the received confirmation information and confirming that the Bluetooth equipment is successfully bound with the user identifier of the application terminal; and the confirmation information is sent after the equipment information, the user identification and the second key data are bound by the server based on the validity verification.

The fifth aspect of the embodiment of the application provides a binding device which is applied to a server, wherein the server communicates with the Bluetooth equipment through an application end, and the application end is carried on terminal equipment; the device comprises:

the second acquisition module is used for acquiring the equipment information of the Bluetooth equipment and the user identification sent by the application end;

the second key module is used for obtaining second key data based on a key negotiation mechanism;

the second binding module is used for binding the equipment information, the user identification and the second key data to obtain a mapping relation in response to the fact that the first key data and the second key data are determined to be effective; wherein the first key data is obtained by the Bluetooth device based on the key negotiation mechanism; the first key data and the second key data are used for the Bluetooth equipment to carry out encrypted communication with the application end;

And the second sending module is used for returning confirmation information to the Bluetooth equipment.

The sixth aspect of the embodiment of the application provides a bluetooth communication device, which is applied to an application end carried on terminal equipment, wherein the application end communicates with a server end; the device comprises:

a third obtaining module, configured to obtain second key data obtained by the server based on a key negotiation mechanism;

the third communication module is used for carrying out encryption communication with the Bluetooth equipment at the Bluetooth application layer based on the first key data and the second key data;

A seventh aspect of the embodiment of the present application provides an electronic device, including:

a processor;

a memory for storing processor-executable instructions;

wherein the processor, when invoking the executable instructions, performs the operations of the method of any of the first to third aspects.

An eighth aspect of the embodiments of the present application provides a computer readable storage medium having stored thereon computer instructions which when executed by a processor implement the steps of the method of any of the first to third aspects.

The application provides a binding method, a communication method, a device, electronic equipment and a medium of Bluetooth equipment, wherein the Bluetooth equipment and an application end are bound by a server end to generate a mapping relation of equipment information, user identification and second key data. Therefore, even if the user changes the terminal equipment to log in the application terminal, the application terminal can acquire the bound second key data from the service terminal according to the user identification in the new terminal equipment, so that the application terminal can communicate with the Bluetooth equipment by utilizing the second key data without rebinding the Bluetooth equipment and the new terminal equipment.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments of the present application will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and should not be considered as limiting the scope, and other related drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is an application scenario provided in an embodiment of the present application.

Fig. 2 is a flow chart of a binding method of a bluetooth device according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a key generation process according to an embodiment of the present application;

fig. 4 is a flowchart of another method for binding bluetooth devices according to an embodiment of the present application;

fig. 5 is a flowchart of another method for binding bluetooth devices according to an embodiment of the present application;

fig. 6 is a flowchart of another method for binding bluetooth devices according to an embodiment of the present application;

fig. 7 is a flowchart of another method for binding bluetooth devices according to an embodiment of the present application;

fig. 8 is a flowchart of another method for binding bluetooth devices according to an embodiment of the present application;

fig. 9 is a flowchart of another method for binding bluetooth devices according to an embodiment of the present application;

fig. 10 is a schematic flow chart of a bluetooth communication method according to an embodiment of the present application;

fig. 11 is a flowchart of another bluetooth communication method according to an embodiment of the present application;

fig. 12 is a flowchart of another bluetooth communication method according to an embodiment of the present application;

fig. 13 is a flowchart of another bluetooth communication method according to an embodiment of the present application;

fig. 14 is a flowchart of another method for binding bluetooth devices according to an embodiment of the present application;

Fig. 15 is a flowchart of another bluetooth communication method according to an embodiment of the present application;

fig. 16 is a block diagram of a binding apparatus of a bluetooth device according to an embodiment of the present application;

fig. 17 is a block diagram of another binding apparatus for bluetooth device according to an embodiment of the present application;

fig. 18 is a block diagram of a bluetooth communication device according to an embodiment of the present application;

fig. 19 is a hardware configuration diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the accompanying drawings in the embodiments of the present application.

It should be noted that: like reference numerals and letters denote like items in the following figures, and thus once an item is defined in one figure, no further definition or explanation thereof is necessary in the following figures. Meanwhile, in the description of the present application, the terms "first", "second", and the like are used only to distinguish the description, and are not to be construed as indicating or implying relative importance.

The term "local end" in the present application refers to an execution body of a method and an apparatus.

At present, communication is often performed between a bluetooth device and a terminal device through a short-distance communication mode such as BLE. The terminal equipment can be provided with a Bluetooth APP matched with the Bluetooth equipment, and a user can use various functions of the Bluetooth equipment after the APP logs in an account.

The bluetooth device refers to a device with BLE connection function, and may include, for example, but not limited to, a smart home device, a wearable device, a virtual reality device, an augmented reality device, or any combination thereof. In some embodiments, the smart home device may include a smart lighting device, a smart monitoring device, a smart television, a smart video camera, or an intercom, or the like, or any combination thereof. In some embodiments, the wearable device may include a smart bracelet, a smart lace, a smart glass, a smart helmet, a smart watch, a smart garment, a smart backpack, a smart accessory, etc., or any combination thereof. In some embodiments, the virtual reality device and/or the augmented reality device may include a virtual reality helmet, a virtual reality glass, a virtual reality patch, an augmented reality helmet, an augmented reality glass, an augmented reality patch, or the like, or any combination thereof. For example, the virtual reality device and/or the augmented reality device may include various virtual reality products, and the like.

The terminal device is a device which has a BLE connection function and can establish a bluetooth channel with the bluetooth device. For example, the terminal device may include, but is not limited to, a tablet computer, a laptop computer, or a built-in device in a motor vehicle, a smart phone, a personal digital assistant (Personal Digital Assistant, PDA), a navigation device, or a point of sale (POS) device, etc., or any combination thereof. In some embodiments, the built-in devices in the motor vehicle may include an on-board computer, an on-board television, and the like.

In the related art, a bluetooth device and a terminal device need to be paired and bound first, and then perform interactive communication. Typically, bluetooth devices pair and bind with terminal devices on the transport layer of BLE. Specifically, the BLE pairing method includes Just Works (direct use), numeric Comparison (numerical comparison), passkey Entry, and Out Of Band (outer Band). The latter three modes are commonly used for pairing between devices, because the latter three modes generate a key in the pairing process, and the key can be continuously used for encrypting interaction data at a transmission layer during interaction communication.

However, since the above key can only be used between the paired bluetooth device and the terminal device. Or, the BLE channel between the bluetooth device and the terminal device is only established based on the device, and has no relation with the APP in the terminal device, so when the user changes the terminal device to log in the APP, the original key between the terminal device and the bluetooth device cannot be used in the communication between the new terminal device and the bluetooth device. As such, the new terminal device and bluetooth device need to be paired and bound again to generate a new key that belongs between them. Similarly, if the user logs in the APP by using the same account number at different terminal devices, each terminal device needs to be paired and bound with the bluetooth device respectively. Obviously, this brings great inconvenience to the user's use.

Therefore, the application provides a binding method, a communication method, a device, an electronic device and a medium of Bluetooth equipment. The Bluetooth device and the application end comprise a binding phase and a communication phase. The Bluetooth device and the application end are bound in a binding stage and then communicate in a communication stage.

First, in the binding phase, the first aspect of the present application provides a binding method of a bluetooth device. Fig. 1 shows an application scenario of the method. As shown in fig. 1, the terminal device 120 is equipped with a client of the bluetooth APP, that is, an application 121. The user may log in to the account number in the application and use the functionality of bluetooth device 110 at the application, configure bluetooth device 110, etc. Correspondingly, the bluetooth APP also has a corresponding server 130, and the application 121 communicates with the server 130. After the bluetooth device 110 establishes a communication connection with the terminal device 120, the bluetooth device 110 may also communicate with the server 130 through the application 121. That is, the bluetooth device 110 and the server 130 do not directly establish a channel, but the application forwards the data of the bluetooth device 110 to the server 130 to realize communication.

The binding method of the bluetooth device provided in the first aspect of the present application is applied to the bluetooth device 110 shown in fig. 1, and includes steps 210-240 shown in fig. 2.

Step 210: transmitting the equipment information of the home terminal to the server terminal;

illustratively, bluetooth device 110 sends the device information to server 130 via application 121.

Alternatively, the bluetooth device 110 may send the device information to the application 121 through a notify function in the GATT protocol, and then the application 121 sends the device information to the server through a channel with the server 130.

Alternatively, the device information may include, but is not limited to, one or more of model parameters, did parameters, and sn parameters. The model parameter is a broadcast PID, and the sn parameter can be read through the information of the 3.0x1800 mechanics equipment.

Step 220: obtaining first key data based on a key negotiation mechanism;

step 230: verifying the validity of the first key data and the second key data;

the second key data is obtained by the server based on the key negotiation mechanism; the first key data and the second key data are used for the Bluetooth equipment to carry out encrypted communication with the application end.

The bluetooth device 110 and the server 130 obtain the first key data and the second key data respectively based on a key negotiation mechanism. The key negotiation mechanism can refer to a key negotiation scheme used for key negotiation in the related art. Based on the key agreement mechanism, bluetooth device 110 is allowed to establish a shared key with server 130 over an unsecured channel. Based on the shared key, first key data and second key data may be obtained. And the first key data and the second key data may be used for communication between the subsequent bluetooth device 110 and the application 121.

Since the first key data and the second key data are locally generated by the bluetooth device 110 and the server 130, respectively, it is necessary to determine whether the first key data and the second key data are available through validity verification. And continuing the next operation if the validity verification is passed.

Step 240: in response to receiving the confirmation information, confirming that the Bluetooth equipment is successfully bound with the user identifier of the application terminal;

and the confirmation information is sent after the equipment information, the user identification and the second key data are bound by the server based on the validity verification.

For example, the server 130 binds the device information obtained from the bluetooth device 110, the user identifier obtained from the application 121, and the locally generated second key data to obtain a mapping relationship between the three when determining that the first key data and the second key data are valid.

The user identification is used for representing the user and is a unique identity identification of the user. When a user logs in the application 121, the identity of the user is represented by the user identifier.

After the binding is completed, the server 130 sends acknowledgement information to the bluetooth device 110 through the application 121. Bluetooth device 110 may determine that the binding of the user id of the home terminal and the application terminal 121 is successful according to the confirmation information.

It can be seen that, in the binding method of bluetooth device provided by the present application, the bluetooth device and the application end execute the steps 210-240 in the binding phase, and the effective first key data and second key data generated in the binding phase are used for encrypting data in the subsequent communication phase. In addition, the Bluetooth device and the application terminal are bound by the server terminal to generate a mapping relation of the device information, the user identification and the second key data. Therefore, even if the user changes the terminal equipment to log in the application terminal, the application terminal can acquire the bound second key data from the service terminal according to the user identification in the new terminal equipment, so that the application terminal can communicate with the Bluetooth equipment by utilizing the second key data without rebinding the Bluetooth equipment and the new terminal equipment. Similarly, when a user logs in the application terminal by using the same account number at different terminal devices, the application terminals in the different terminal devices can acquire the same second key data from the service terminal by using the same user identifier, and communicate with the Bluetooth device by using the second key data.

Compared with the method for establishing the BLE channel based on the equipment in the related art, the method for establishing the BLE channel based on the equipment does not bind the Bluetooth equipment and the terminal equipment any more, or the method for establishing the BLE channel based on the equipment does not bind the Bluetooth equipment and the user identification of the application end any more, so that the user can acquire the second key data communicated with the Bluetooth equipment by utilizing the user identification no matter which terminal equipment logs in the application end, thereby realizing decoupling between the Bluetooth equipment and the terminal equipment and improving user experience.

Steps 210-240 are described in detail below.

As described above, in the related art, the bluetooth device 110 and the terminal device 120 generate a key when paired using any pairing method Of Numeric Comparison, passkey Entry, or Out Of Band at the transmission layer. And the generated key can be used for encryption of data in a subsequent communication phase. Accordingly, in the related art, the bluetooth device 110 and the terminal device 120 often complete encryption of data at the transmission layer in the communication phase.

In some embodiments of the present application, based on the above binding method, the bluetooth device 110 and the terminal device 120 may communicate in the non-authentication mode at the bluetooth transmission layer during the binding phase.

The so-called non-authentication mode, i.e. the use between the bluetooth device 110 and the terminal device 120 is directly possible without authentication and approval. In the non-authentication mode, no key is generated between the devices. Alternatively, the non-authentication mode may be Just Works pairing as described above.

Since no key is generated during the binding phase, the data is not encrypted in the transport layer during the subsequent communication phase. Since the data is not encrypted at the transport layer, the Bluetooth device 110 and the terminal device 120 do not need to be paired and bound to generate a key after the device is replaced.

Conversely, if the bluetooth device 110 and the terminal device 120 use the pairing method for generating the key in the binding phase, and if the key is used for data encryption in the communication phase, the bluetooth device 110 and the terminal device 120 still need to be paired and bound again after the device is replaced to generate a new key for data encryption.

Further, in the case of the non-authentication mode, the data is not encrypted at the transmission layer, so to ensure the security of the data, in some embodiments, the data may be encrypted at the bluetooth application layer by using the first key data and the second key data. Specifically, the encrypted communication process at the bluetooth application layer will be described below, and is not developed here.

It can be seen that in this embodiment, by setting that the bluetooth device and the terminal device communicate in the bluetooth transmission layer through the non-authentication mode, it is ensured that the application end does not need to be paired and bound with the bluetooth device again after replacing the terminal device.

The process of generating the first key data in step 220 and the process of generating the second key data in the server are described below.

As shown in fig. 3, the bluetooth device 110 is preset with a first public-private key pair, and the server 130 is preset with a second public-private key pair. For example, the first public-private key pair may be a first temporary public-private key pair (pub_d_tk, pri_d_tk) that the bluetooth device 110 temporarily generates when performing the present method. The second public-private key pair may be a second temporary public-private key pair (pub_s_tk, pri_s_tk) temporarily generated by the server 130 when the present method is performed. The bluetooth device 110 and the server 130 may exchange temporary public keys pub_d_tk and pub_s_tk with each other. The encryption algorithm used may be an ECC (EllipseCurve Ctyptography, elliptic curve encryption) algorithm, among others.

With continued reference to fig. 3, bluetooth device 110 may generate a first shared key share key 1 based on a key negotiation mechanism, a second temporary public key pub_s_tk of server 130, and a first temporary private key pri_d_tk of the server.

The server 130 may generate a second shared key share_key_2 based on the key negotiation mechanism, the first temporary public key pub_d_tk of the bluetooth device 110, and the second temporary private key pri_s_tk of the local.

Wherein optionally the key agreement mechanism may be an ECDH (Elliptic Curve Diffie-Hellman key Exchange ) algorithm.

Thus, the first shared key share_key_1=ecdh (pub_s_tk, pri_d_tk); second shared key_key_2=ecdh (pub_d_tk, pri_s_tk).

Subsequently, bluetooth device 110 may obtain first key data based on the first shared key; the server 130 may obtain second key data based on the second shared key.

As an example, the first shared key share_key_1 may be directly determined as the first key data, and the second shared key share_key_2 may be the second key data.

As an example, to meet the cryptographic strength requirement, as shown in fig. 3, the bluetooth device 110 may derive the first derivative key determined_key_1 using the first shared key share_key_1, and determine the first derivative key determined_key_1 as the first key data. The server 130 may derive the second derivative key determined_key_2 by using the second shared key share_key_2, and determine the second derivative key determined_key_2 as the second key data.

Wherein, optionally, bluetooth device 110 and server 130 may utilize HKDF (HMAC-based Key Derivation Function ) algorithm for key derivation. Wherein the first shared key share_key_1 and the second shared key share_key_2 are IKM (input keying material, original key material) in the HKDF algorithm. The random elements used in the HKDF algorithm, including salt and info, are preset. For example, salt may be 16 bytes of fixed data and info may be a fixed string.

Thus, the first derivative key derived_key_1=hkdf (share_key_1, salt, info), and the resulting first derivative key derived_key_1 is composed of 48 bytes.

The second derivative key derived_key_2=hkdf (share_key_2, salt, info). The resulting first derivative key derived_key_1 comprises 48 bytes.

As an example, as shown in fig. 3, the first derivative key determined_key_1 may be split into a plurality of first sub-keys, the first key data including the first sub-keys; similarly, the second derivative key, derived_key_2, may be split into a plurality of second sub-keys, the second key data comprising the second sub-keys.

Illustratively, the 48 bytes of the first derivative key determined_key_1 may be divided into 3 different first sub-keys. For example, the first 16 bytes as the first device key_key_1; the middle 16 bytes are used as a first token key_key_1; the last 16 bytes are used as the first identity key ir_key_1.

Similarly, the 48 bytes of the second derivative key defined_key_2 may be divided into 3 different second sub-keys in the same manner, to obtain a second device key device_key_2, a second token key_key_2, and.

The first device key_key_1 and the second device key_key_2 are used for data encryption in a binding stage. The first token key_key_1 and the second token key_key_2 are used for data encryption in the subsequent communication stage. The first identity key ir_key_1 and the second identity key ir_key_2 are used to verify whether the bluetooth device 110 is a history bound device and/or whether the application 121 is a history bound application.

In some embodiments, in the process of generating the first key data and the second key data, the bluetooth device 110 and the server 130 respectively perform authentication on the opposite ends.

Illustratively, the bluetooth device 110 and the server 130 respectively perform authentication on the opposite ends based on signature verification.

Specifically, the bluetooth device 110 is preset with a third public-private key pair, and the server 130 is preset with a fourth public-private key pair. For example, the third public-private key pair may be a first long-term public-private key pair (pub_d_ ltk, pri_d_ ltk) that was previously generated by the bluetooth device 110. The fourth public-private key pair may be a second long-term public-private key pair (pub_s_ ltk, pri_s_ ltk) pre-generated by the server 130. The bluetooth device 110 and the server 130 may exchange long-term public keys pub_d_ ltk and pub_s_ ltk with each other.

In the process of generating the first key data and the second key data, the identity verification process of the bluetooth device 110 on the server 130 is as follows:

in response to the application 121 sending a Binding command < Start Binding > to the bluetooth device 110, the bluetooth device 110 generates a first random number random_d1. Optionally, the first random number random_d1 is 10 bytes. Subsequently, the bluetooth device 110 sends the first random number random_d1 to the server 130 through the application 121. Optionally, the first random number random_d1 may be sent to the server 130 together with the device information through the application 121 in step 210.

In response to receiving the first random number random_d1, the server 130 generates a fifth signature sign_s using the first random number random_d1, the second temporary public key pub_s_tk of the server, and the second long-term private key pri_s_ ltk of the server. For example, the first random number random_d1 and the second temporary public key pub_s_tk may be formed into a plaintext random_d1||pub_s_tk, and the plaintext random_d1||pub s_tk may be signed by using the second long-term private key pri_s_ ltk to obtain the fifth signature sign_s. Alternatively, the signature algorithm used may be ECDSA (Elliptic Curve Digital Signature Algorithm ), and the hash function used in the signature algorithm may be SHA256 algorithm.

Subsequently, the server 130 returns the fifth signature sign_s to the bluetooth device 110. The bluetooth device 110 signs the fifth signature sign_s using the first random number random_d1, the second temporary public key pub_s_tk of the server 130, and the second long-term public key pub_s_ ltk of the server 130. For example, the first random number random_d1 and the second temporary public key pub s tk may be combined into a plaintext random_d1 pub s tk, the fifth signature sign_s is signed with the second long-term public key pub_s_ ltk. In the case that the fifth signature sign_s passes verification, the identity of the server 130 passes verification.

Alternatively, the bluetooth device 110 may regenerate the first key data in case the authentication of the server 130 is passed, i.e. in case the authentication of the fifth signature_s is passed.

The authentication of the bluetooth device 110 to the server 130 in the generation process of the first key data and the second key data is completed.

In the process of generating the first key data and the second key data, the identity verification process of the server 130 on the bluetooth device 110 is as follows:

the server 130 generates a second random number random_s. Alternatively, the second random number random_s is 10 bytes. Subsequently, the server 130 sends the second random number random_s to the bluetooth device 110 through the application 121. Optionally, the second random number random_s may be returned to the bluetooth device 110 together with the fifth signature sign_s.

In response to receiving the second random number random_s, the bluetooth device 110 generates a sixth signature sign_d using the second random number random_s, the first temporary public key pub_d_tk of the home terminal, and the first long-term private key pri_d_ ltk of the home terminal ₁ . For example, the second random number random_s may be combined with the first temporary public key pub d tk into a plaintext random s pub d tk, signing the plaintext random_s||pub_d_tk with the first long-term private key pri_d_ ltk to obtain a sixth signature sign_d ₁ . Alternatively, the signature algorithm used may be ECDSA and the hash function used in the signature algorithm may be SHA256 algorithm.

Subsequently, bluetooth device 110 will sign_d the sixth signature ₁ Returns to the server 130. The server 130 signs the sixth signature_d using the second random number random_s, the first temporary public key pub_d_tk of the bluetooth device 110, and the first long-term public key pub_d_ ltk of the bluetooth device 110 ₁ And (5) checking the labels. For example, the second random number random_s may be combined with the first temporary public key pub d tk into a plaintext random s pub d tk, sixth signature sign_d using first long-term public key pub_d_ ltk ₁ And (5) checking the labels. In the sixth signature sign_d ₁ In the case of authentication passing, the identity of bluetooth device 110 passes.

For example, the server 130 may send the second signature sign_d to the bluetooth device 110 ₁ And if the verification is passed, regenerating the second key data.

The identity verification of the bluetooth device 110 by the server 130 in the process of generating the first key data and the second key data is completed.

Regarding the validity verification of the first key data and the second key data in step 230, it can be understood that, since the first key data and the second key data are obtained by different devices through the key negotiation mechanism, if any key data is wrong in the generation process, the key data is not available. It is necessary to verify the validity of the first key data and the second key data.

In some embodiments, the step 230 may include steps 231-232 as shown in fig. 4. The bluetooth device may verify whether the first key and the second key data are valid by performing steps 231-232.

Step 231: verifying whether the first key data matches the second key data;

step 232: and in the case of a match, determining that the first key data and the second key data are valid.

Illustratively, the first key data matches the second key data, which may be the first key data is consistent with the second key data. I.e. bluetooth device 110 and application 121 generate the same key data based on a key negotiation mechanism. It will be appreciated that the valid first key data is consistent with the valid second key data, except that the valid first key data is generated by bluetooth device 110 and the valid second key data is generated by server 130.

It can be seen that the present embodiment verifies the validity of the two key data by determining whether the first key data and the second key data match, thereby ensuring the correctness when the first key data and the second key data are used for encryption in the following.

In the process of verifying whether the key data are matched, in order to prevent the key data from being monitored in the transmission process, the first key data and the second key data are not directly sent to the opposite terminal for comparison. As such, in some embodiments, the first key data and the second key data may be verified as matching by a signed method.

Specifically, the first key data includes a first device key_key_1, and the second key data includes a second device key_key_2. The step 232 may include steps 2321-2323 as shown in fig. 5.

Step 2321: signing by using the first equipment key to obtain a first signature value;

step 2322: acquiring a second signature value obtained by the application terminal by signing based on the second equipment key;

step 2323: and if the first signature value is consistent with the second signature value, determining that the first key data is matched with the second key data.

Step 2321 and step 2322 are not sequentially performed.

It is known that the bluetooth device 110 signs based on the first device key_key_1 to obtain a first signature value confirm_a_1. And the application end 121 signs based on the second device key_key_2 to obtain a second signature value confirm_a_2.

However, since the second key data is generated by the server 130, the application 121 first obtains the second key data from the server 130 before signing.

Alternatively, the application 121 may obtain the generated second shared key share_key_2 from the server 130, derive the second derivative key derived_key_2 by using the second shared key share_key_2 by the application 121, and split the second derivative key derived_key_2 into a plurality of second sub-keys, thereby obtaining the second device key device_key_2.

Alternatively, the application 121 may obtain the generated second derivative key determined_key_2 from the server 130, and then the application 121 splits the second derivative key determined_key_2 into a plurality of second sub-keys, thereby obtaining the second device key device_key_2.

Alternatively, the application may directly obtain the second key data from the server 130, and then obtain the second device key_key_2 from the second key data.

In the above process, the application 121 can obtain the second token key_key_2 and the second identity key ir_key_2 in addition to the second device key_key_2.

The bluetooth device 110 and the application 121 sign with the first device key_key_1 and the second device key_key_2, respectively, based on the same plaintext. Wherein at least part of the plaintext may be determined by the application 121, e.g. a part of the plaintext is randomly generated by the application 121, and another part of the plaintext is generated by other means.

In this way, the application 121 may send a part of the plaintext generated randomly to the bluetooth device 110, and the bluetooth device 110 and the application 121 generate another part of the plaintext in the same manner, so that the bluetooth device 110 and the application 121 both obtain the plaintext.

Alternatively, the signature algorithm used may be a HMAC (Hash-based Message Authentication Code, hash message authentication code) algorithm, and the Hash function used in the signature algorithm may be a SHA256 algorithm. Of course, signature algorithms other than the HMAC algorithm, such as the ECDSA algorithm, may be used, and the application is not limited in this regard.

Thus, the bluetooth device 110 and the application 121 each locally sign the same plaintext using the same signing algorithm and key, and obtain the first signature value confirm_a_1 and the second signature value confirm_a_2, respectively. In the case where the first signature value confirm_a_1 is consistent with the second signature value confirm_a_2, the bluetooth device 110 may determine that the first device key device_key_1 is consistent with the second device key_key_2.

Since the first device key_key_1 and the second device key_key_2 are generated by the first shared key share_key_1 and the second shared key share_key_2, the first derivative key derived_key_1 and the second derivative key derived_key_2, it can be determined that the first token key_key_1 and the second token key_key_2 are identical and the first identity key ir_key_1 and the second identity key ir_key_2 are identical in the case that the first device key_key_1 and the second device key_key_2 are identical. It may then also be determined that the first derivative key determined_key_1 is consistent with the second derivative key determined_key_2 and that the first shared key share_key_1 is consistent with the second shared key share_key_2. It is known that the first key data matches the second key data, i.e. the first key data and the second key data are valid.

Therefore, the embodiment realizes the validity verification of the first key data and the second key data under the condition of not transmitting the key data in a signature mode, thereby preventing the key data from being monitored in the transmission process and ensuring the safety of the key data.

Further, to ensure that the application 121 is bound to the correct bluetooth device 110, in some embodiments, the binding method further includes steps 610-630 as shown in fig. 6 during the binding phase.

Step 610: generating and outputting first verification information;

step 620: receiving a confirmation instruction input by a user based on the first verification information and the second verification information;

the second verification information is generated by the server and output by the application end;

step 630: and determining the home terminal as the equipment to be bound based on the confirmation instruction.

As can be seen, the bluetooth device 110 generates the first authentication information oob _1, and outputs the first authentication information oob _1 at the home terminal. The server 130 generates the second verification information oob _2, sends the second verification information oob _2 to the application 121, and the application 121 outputs the second verification information oob _2.

The output manners of the bluetooth device 110 and the application 121 may include, but are not limited to, display output, voice output, and the like. The forms of the first authentication information oob _1 and the second authentication information oob _2 may include, but are not limited to, one or more of characters, data, patterns, animation, sounds. The specific output manner and the specific form of the verification information may be determined according to the output capabilities of the bluetooth device 110 and the terminal device 120.

After the bluetooth device 110 and the application 121 output the first authentication information oob _1 and the second authentication information oob _2, respectively, the user may input a confirmation instruction in the bluetooth device 110 and/or the application 121 based on the first authentication information oob _1 and the second authentication information oob _2. For example, the user may determine whether the first authentication information oob _1 and the second authentication information oob _2 are consistent, and input a confirmation instruction if they are consistent. In the case of inconsistency, no acknowledgement command is entered, or no negative command is entered.

Based on the confirmation instruction, bluetooth device 110 and/or application 121 may determine that bluetooth device 110 is the device to be bound. In this way, the application 121 is guaranteed to bind to the correct bluetooth device 110 by manual comparison.

Regarding the generation process of the first authentication information oob _1 and the second authentication information oob _2, taking the first authentication information oob _1 and the second authentication information oob _2 as numbers as examples, in some embodiments, the bluetooth device 110 and the server 130 can generate the first authentication information oob _1 and the second authentication information oob _2 based on the first temporary public key pub_d_tk and the second temporary pub_s_tk. The first verification information oob _1 and the second verification information oob _2 may be generated simultaneously without any sequence of generation.

In view of the limited display capabilities of bluetooth device 110 and/or terminal device 120, multi-digit numbers cannot be output and it is also difficult for a user to check each digit of the multi-digit numbers. Therefore, the number of bits of the first verification information oob _1 and the second verification information oob _2 should not be too large. However, public and private key pairs typically have a large number of bits, and a remainder process may be performed to reduce the number of bits.

For example, the bluetooth device 110 and the server 130 may take a hash value from the sum of the first temporary public key pub_d_tk and the second temporary public key pub_s_tk, and then perform a remainder processing on the hash value to obtain the first verification information oob _1 and the second verification information oob _2. Namely:

oob_1＝SHA256(pub_s_tk+pub_d_tk)mod 10^n；

oob_2＝SHA256(pub_s_tk+pub_d_tk)mod 10^n。

where the value of n is related to the display capabilities of bluetooth device 110 and/or terminal device 120. For example, if bluetooth device 110 and/or terminal device 120 can only display 6 digits, n may take 6 digits, such that both first authentication information oob _1 and second authentication information oob _2 are a 6-digit number.

It is known that, in the case that the bluetooth device 110 is a device to be bound, the first authentication information oob _1 and the second authentication information oob _2 should be identical, but the first authentication information oob _1 is generated in the bluetooth device 110 and the second authentication information oob _2 is generated in the server 130.

Further, as described in the embodiment of fig. 5, the bluetooth device 110 and the application 121 each locally sign the same plaintext, and use the same signing algorithm and the same secret key to obtain the first signature value confirm_a_1 and the second signature value confirm_a_2, respectively. Wherein a portion of the plaintext may be randomly generated by the application 121 and another portion of the plaintext may be generated by other means.

In some embodiments, another portion of the plaintext may be the first authentication information oob _1 and the second authentication information oob _2. And a portion of the plaintext randomly generated by the application 121 may be random_a. Alternatively, random_a may include 10 bytes.

I.e., bluetooth device 110 is configured to determine, for range a and first authentication information oob _1, plain text can be obtained random_a| i oob _1. The application 121 for random a and the second authentication information oob _2, plain text can be obtained random_a| i oob _2.

It is known that, in the case that the bluetooth device 110 is a device to be bound, the first authentication information oob _1 and the second authentication information oob _2 should be identical, so that the plaintext random_a|| oob _1 and the plaintext random_a|| oob _2 are also identical. In this way, the first signature value confirm_a_1 obtained by signing with the first device key_key_1 is also identical to the second signature value confirm_a_2 obtained by signing with the second device key_key_2, and it is thereby possible to determine that the first key data matches the second key data.

In some embodiments, after the validity of the first key data and the second key data is verified, verification of communication security may also be performed between the bluetooth device 110 and the server 130.

For example, the server 130 may generate a random string random_bind and send the random string random_bind to the bluetooth device 110 through the application 121.

After the validity of the first key data and the second key data passes, the bluetooth device 110 may sign the random string random_bind with the first shared key share_key_1 to obtain a seventh signature bind_sign_1.

Subsequently, bluetooth device 110 may send a seventh signature bind_sign_1 to application 121. After the validity of the first key data and the second key data is verified, the application 121 sends the seventh signature bind_sign_1 to the server 130. The verification of the validity of the first key data and the second key data by the application 121 will be described below.

In response to receiving the seventh signature bind_sign_1, the server 130 verifies the seventh signature bind_sign_1. Illustratively, the server 130 may sign the random string random_bind with the second shared key share_key_2 to obtain an eighth signature bind_sign_2.

Wherein, optionally, the signature algorithm used by the seventh signature bind_sign_1 and the eighth signature bind_sign_2 may be an HMAC algorithm, and the hash function used in the signature algorithm may be a SHA256 algorithm. As such, bind_sign_1=hmac_sha256 (share_key_1, random_bind). bind_sign_2=hmac_sha256 (share_key_2, random_bind). Of course, signature algorithms other than the HMAC algorithm, such as the ECDSA algorithm, may be used, and the application is not limited in this regard.

In this way, when the seventh signature bind_sign_1 matches the eighth signature bind_sign_2, it is confirmed that the communication security between the bluetooth device 110 and the server 130 is verified.

Based on this, since the seventh signature bind_sign_1 is generated after the validity verification of the first key data and the second key data is passed, in some embodiments, the server 130 may confirm that the first key data and the second key data are valid based on receiving the seventh signature bind_sign_1. That is, the seventh signature bind_sign_1 may also be used to inform the server 130 that the first key data and the second key data are valid in this embodiment.

Of course, bluetooth device 110 and/or application 121 may also inform server 130 that the first key data and the second key data are valid in other manners. For example, notification information or the like may be sent to the server 130.

In this way, the server 130 may bind the device information of the bluetooth device 110, the user identifier of the application 121, and the second key data based on the validity verification, to obtain the mapping relationship. After binding is completed, the server 130 sends acknowledgement information to the bluetooth device 110. In step 240, the bluetooth device 110 may determine that the home terminal and the user identifier of the application terminal are successfully bound according to the acknowledgement information.

Regarding the confirmation information, in some embodiments, the encrypted information may be sent to bluetooth device 110 by the server, and the form of whether bluetooth device 110 can successfully decrypt the encrypted information informs bluetooth device 110 whether the binding was successful.

Illustratively, after the binding is completed, the server 130 may encrypt the binding data bound_data with the second device key_key_2 to obtain encrypted information encrypted_data_1.

Alternatively, encryption may be performed using a GCM (Galois/Counter Mode ) Mode in the AES (Advanced Encryption Standard, advanced encryption Standard) algorithm, with GCM-iv being a fixed 12-byte length.

Thus, the encrypted information encrypted_data_1=iv+aes_gcm (devcie_key_2, bonded_data).

After the encrypted information encrypted_data_1 is sent to the bluetooth device 110 through the application 121, the bluetooth device 110 may decrypt with the first device key_key_1. If the decryption is successful, and the binding data bind_data is obtained, the bluetooth device 110 may determine that the home terminal and the user id of the application terminal 121 are successfully bound.

Alternatively, bluetooth device 110 may then notify application 121 that the binding was successful. The application 121 may output a prompt for successful binding.

So far the description of the binding phase between the bluetooth device 110 and the application 121 is completed.

The following describes the communication phase between the bluetooth device 110 and the application 121.

In some embodiments, after the bluetooth device 110 confirms that the binding is successful, the method may further include the steps of: and carrying out encryption communication with the application end at a Bluetooth application layer based on the first key data and the second key data.

As described above, when the bluetooth device 110 and the terminal device 120 communicate in the non-authentication mode at the transport layer, then the interactive data in the communication phase is no longer encrypted at the transport layer. In order to ensure the security of data transmission, the interactive data in the communication stage can be encrypted by using the first key data and the second key data at the application layer.

It will be appreciated that in the related art, the application layer specifications define three types, including characteristics, services, and specifications. These conventions are built on generic property specifications that define property groupings for properties and services, and applications define conventions for using these property groupings. That is, in the related art, the application layer is not responsible for encryption of data. However, in this embodiment, under the condition that the transmission layer does not encrypt the data any more, it is designed to encrypt and communicate with the second key data by using the first key data at the application layer, so as to ensure the communication security.

In some embodiments, the first key data comprises a first token key_key_1 and the second key data comprises a second token key_key_1. In this way, the encrypting communication between the bluetooth application layer and the application end based on the first key data and the second key data may include steps 710 to 730 shown in fig. 7.

Step 710: generating a first session key based on the first token key;

step 720: the identity of the application terminal is verified by utilizing the first session key and the second session key;

wherein the second session key is generated by the application based on the second token key;

it is known that the bluetooth device 110 derives the first session key session_key_1 by using the first token key_key_1. The application 121 derives the second session key_key_2 by using the second token key_key_2. Wherein the application 121 has acquired the second token key_key_2 from the server 130 in the binding phase (see the above embodiment), so that the second token key_key_2 can be directly used for key derivation in the communication phase.

Alternatively, the key derivation algorithm used may be the HKDF algorithm. The first token key_key_1 and the second token key_key_2 are IKM in the HKDF algorithm, and random elements used in the HKDF algorithm, including salt and info, are preset. As an example, the first session key_key_1 and the second session key_2 each include 16 bytes.

Subsequently, bluetooth device 110 may authenticate using the first session key_key_1 and the second session key_key_2. The authentication may be performed by means of a signature, for example.

Specifically, the application 121 may generate the first random string rand_app and send the first random string to the bluetooth device 110, and the bluetooth device 110 may generate the second random string rand_d. Wherein, the first random string rand_app and the second random string rand_d each comprise 10 bytes.

Subsequently, bluetooth device 110 may generate a ninth signature sign_d based on the first session key_key_1, the first random string rand_app, and the second random string rand_d ₂ 1. For example, the first random string rand_app and the second random string rand_d may be combined into plaintext rand_app_rand_d, using the first session secretThe plaintext rand_app||rand_d is signed by the key session_key_1 to obtain a ninth signature sign_d ₂ _1。

Subsequently, the bluetooth device 110 may compare the second random string rand_d with the ninth signature sign_d ₂ 1 is returned to the application 121. The application 121 may generate a tenth signature sign_d based on the second session key_key_2, the first random string rand_app, and the second random string rand_d ₂ 2. Similarly, the first random string rand_app and the second random string rand_d may be combined into a plaintext rand_app|rand_d, and the plaintext rand_app|rand_d may be signed by using the second session key_key_2 to obtain a tenth signature sign_d ₂ _2。

Alternatively, the signature algorithm used may be an HMAC algorithm and the hash function used in the signature algorithm may be a SHA256 algorithm.

Thus, sign_d ₂ _1＝HMAC_SHA256(session_key_1,rand_app||rand_d)；

sign_d ₂ _2＝HMAC_SHA256(session_key_2,rand_app||rand_d)。

It can be seen that if the ninth signature sign_d ₂ 1 and tenth signature sign_d ₂ 2, identity verification passing can be determined.

Step 730: and in response to the authentication passing, carrying out encrypted communication with the application end at a Bluetooth application layer based on the first session key and the second session key.

The application 121 may further encrypt the information deviceInfo with the second session key_key_2 to obtain encrypted data encrypted_data_2, and send the encrypted data encrypted_data_2 to the bluetooth device 110. Bluetooth device 110 may decrypt using first session key_key_1 and may further notify application 121 that the session establishment was successful if the decryption was successful.

After the session is established, the bluetooth device 110 and the application 121 may use the first session key session_key_1 and the second session key_key_2 to encrypt and decrypt during data interaction, where the encryption algorithm may include an aes_gcm algorithm, and the format of the encrypted data may be iv_size+iv+aes_gcm (data).

So far, the description of the communication phase between the bluetooth device 110 and the application 121 is completed.

The following describes a reconnection phase of the connection of the application 121 with the bluetooth device 110 when the replacement terminal device logs in to the application.

It can be understood that, if the application 121 completes binding with the bluetooth device 110 at the first terminal device, when the user replaces the second terminal device with the application 121, the application 121 cannot establish a communication connection with the bluetooth device 110 at the second terminal device because the second terminal device does not store the second key data and the bluetooth address of the bluetooth device 110. In this manner, in the reconnection phase, the application terminal 121 can be reconnected to the bluetooth device 110 by the scheme described in the following embodiment.

In some embodiments, the first key data comprises a first identity key ir_key_1 and the second key data comprises a second identity key ir_key_2. As such, the above method may further comprise the steps of:

and in response to the first connection with the terminal equipment, broadcasting an encrypted message encrypted by using the first identity key, so that an application terminal loaded on the terminal equipment decrypts the encrypted message by using a second identity key acquired from the service terminal, and determining that the application terminal is a history binding application terminal under the condition that decryption is successful.

The terminal device in the above step may be, for example, the second terminal device, that is, a terminal device where the application terminal 121 is located, different from the terminal device where the application terminal 121 is bound to the bluetooth device 110.

When there is no application in communication with bluetooth device 110, the bluetooth device may broadcast an encrypted message encrypted with first identity key ir_key_1.

After the login account, the application 121 installed in the new terminal device may decrypt the encrypted message by using the second identity key ir_key_2. Wherein the second identity key ir_key_2 is obtained from the server 130 according to the user identification. If the decryption is successful, it indicates that the server 130 has bound the bluetooth device 110 with the user id, where the bluetooth device 110 is a history binding device, and the application 121 is a history binding user.

The application 121 obtains the second identity key ir_key_2 from the server 130. Since the server 130 binds the device information of the bluetooth device 110, the user identifier of the application 121, and the second key data, after the terminal device is replaced to log in the application 121, the application 121 may acquire the corresponding second key data from the server 130 by using the user identifier.

Optionally, the second key data obtained by the application 121 from the server 130 includes at least a second identity key ir_key_2 and a second token key_key_2. That is, the application 121 may not acquire the second device key_key_2. This is because the second identity key ir_key_2 is used to determine if the bluetooth device is a history bound device, and if so, the second token key_key_2 is used for encrypted communication in a subsequent communication phase. While the second device key 2 is used for data encryption during the binding phase, no later process needs to utilize the second device key 2 regardless of whether the bluetooth device is a history binding device. The application 121 may not acquire the second device key_key_2.

The process of the application terminal 121 obtaining the second key data from the server terminal 130 may refer to the process of the application terminal 121 obtaining the second key data from the server terminal 130 described in the above embodiment. The present application is not described in detail herein.

Further, after determining that the application 121 is a history-bound application, the bluetooth device 110 and the application 121 may perform encrypted communication at the application layer by using the first key data and the second key data. The specific communication process can be referred to the description of the communication stage above, and will not be repeated here.

It can be seen that, in this embodiment, in the reconnection stage, the bluetooth device 110 encrypts the message by using the first identity key encryption, and broadcasts the obtained encrypted message, so that the application 121 attempts to decrypt the encrypted message by using the second identity key obtained from the server. And under the condition that decryption is successful, determining that the application end is the application end bound in history, so that the Bluetooth equipment does not need to be bound with the application end again or a new terminal equipment.

Therefore, the application generates the effective first key data and the effective second key data in the binding phase of the Bluetooth equipment and the application end. In the binding phase, the first device key in the first key data is utilized to carry out encryption communication with the second device key in the second key data; in the communication stage, the first token key in the first key data and the second token key in the second key data are used for encryption communication on the application layer, so that the scheme of pairing, binding and encryption communication between the original Bluetooth equipment and the terminal equipment on the Bluetooth transmission layer is omitted, and the application layer is used for bearing the data encryption instead. Since the transport layer no longer generates keys specific to inter-device encryption, there is no need to rebind the bluetooth device with the terminal device even if the terminal device is replaced.

In addition, after the replacement terminal device logs in the application terminal, the application terminal obtains the bound second data key from the server through the user identifier, decrypts the broadcasted encrypted message by utilizing the second identity key, and can directly enter a communication stage to communicate with the Bluetooth device under the condition of successful decryption. Therefore, the binding relation between the Bluetooth equipment and the terminal equipment is decoupled, the Bluetooth equipment is bound with the user identifier, the whole reconnection process is insensitive to the user, and the user experience is improved.

In addition, in the binding phase, the second aspect of the present application further provides a binding method of the bluetooth device, which is applied to the server 130 shown in fig. 1, and includes steps 810-840 shown in fig. 8.

Step 810: acquiring equipment information of the Bluetooth equipment and a user identifier sent by the application terminal;

the device information of the bluetooth device 110 may include, but is not limited to, one or more of model parameters, did parameters, and sn parameters. And the device information may be sent to the server 130 through the application 121 together with the user identification. The user identification is used for representing the user and is the unique identity identification of the user. When a user logs in the application 121, the identity of the user is represented by the user identifier.

Step 820: obtaining second key data based on a key negotiation mechanism;

step 830: binding the equipment information, the user identification and the second key data to obtain a mapping relation in response to determining that the first key data and the second key data are effective;

wherein the first key data is obtained by the Bluetooth device based on the key negotiation mechanism; the first key data and the second key data are used for the Bluetooth equipment to carry out encrypted communication with the application end;

the process of the bluetooth device 110 and the server 130 obtaining the first key data and the second key data based on the key negotiation mechanism is described in the embodiment of fig. 3.

When the server 130 determines that the first key data and the second key data are valid, for example, the seventh signature bind_sign_1 described in the above embodiment confirms that the first key data and the second key data are valid, the device information, the user identifier and the second key data are bound, so as to obtain and store a mapping relationship.

Step 840: and returning confirmation information to the Bluetooth equipment.

In some embodiments, during the binding phase, the server 130 may send the second key data to the application 121, so that the application 121 performs validity verification using the second key data during the binding phase, and performs encrypted communication with the bluetooth device 110 at the application layer using the second key data during the communication phase.

The process of the server 130 sending the second key data to the application 121 may refer to the process of the application 121 obtaining the second key data from the server 130 described in the above embodiment.

In some embodiments, when the replacement terminal device logs on to the application terminal, the method further includes steps 910-920 shown in fig. 9 in the reconnection phase of the bluetooth device 110 and the application terminal 121.

Step 910: responding to the key request of the application end, and determining second key data corresponding to the user identification based on the mapping relation between the user identification carried by the key request and the user identification;

wherein the key request is initiated when the terminal device is first connected with the bluetooth device.

It can be known that, when the terminal device is first connected to the bluetooth device 110, the application 121 may initiate a key request carrying the user identifier to the server 130.

The user identifier may be an identifier corresponding to a user logging into the application terminal 121. That is, when the user does not log on the application 121, the application cannot obtain the user identifier, and thus cannot obtain the second key data from the server 130.

In addition, the terminal device in step 910 is different from the terminal device where the application terminal 121 is located when the application terminal 121 is bound to the bluetooth device 110. For example, if the application end 21 is bound to the bluetooth device 110 and the application end 121 is mounted on the first terminal device, the terminal device in step 910 may be a second terminal device.

Because the server 130 pre-stores the mapping relation between the device information, the user identifier and the second key data, in response to the key request, the corresponding second key data can be determined according to the usage identifier and the mapping relation.

Step 920: and returning the second key data to the application end so that the application end can carry out encrypted communication with the Bluetooth equipment based on the second key data.

Upon determining the second key data corresponding to the user identifier, the server 130 may return the second key data to the application 121.

The returned second key data at least includes the second identity key ir_key_2 and the second token key_key_2, so that the application end 121 uses the second identity key ir_key_2 to determine whether the bluetooth device 110 is a history binding device, and uses the second token key_key_2 to perform encrypted communication with the bluetooth device 110 at the application layer.

In addition, the third aspect of the present application further provides a bluetooth communication method, which is applied to the application end 121 shown in fig. 1, and includes steps 1010-1020 shown in fig. 10.

Step 1010: acquiring second key data obtained by the server based on a key negotiation mechanism;

step 1020: encrypting communication with the Bluetooth device at a Bluetooth application layer based on the first key data and the second key data;

After acquiring the second key data, the application 121 may perform encrypted communication with the bluetooth device 110 at the bluetooth application layer based on the first key data and the second key data.

In some embodiments, step 1010 described above applies to the binding phase, and as such, step 1010 may include: and in the binding stage of the Bluetooth equipment, acquiring second key data sent by the server.

The process of the application 121 obtaining the second key data from the server 130 described in the above embodiment may be referred to as the application 121 obtaining the second key data in the binding phase.

Further, in some embodiments, in the binding phase, bluetooth device 110 communicates with terminal device 120 in a bluetooth transport layer via a non-authentication mode.

In the non-authentication mode, no key is generated between bluetooth device 110 and terminal device 120. In this way, the data is not encrypted in the transport layer. The non-authentication mode may be, for example, a Just Works mode.

As described above, since the first key data and the second key data are obtained by different devices through the key negotiation mechanism, if any key data is wrong in the generation process, the key data is not available. It is necessary to verify the validity of the first key data and the second key data.

The above describes that the bluetooth device 110 verifies whether the first key data and the second key data are valid. In addition to bluetooth device 110, application 121 also needs to verify whether the first key data and the second key data are valid.

Thus, in some embodiments, during the binding phase, the application 121 also performs the steps of: and verifying the validity of the first key data and the second key data.

Illustratively, the application 121 may verify whether the first key data and the second key data are valid by performing steps 231-232 as shown in fig. 4.

Wherein in step 231 it is determined whether the first key data and the second key data are valid by verifying whether they match.

The embodiment of fig. 5 above describes that bluetooth device 110 verifies that the first key data and the second key data match by means of the first signature value confirm_a_1 and the second signature value confirm_a_2. The following describes that the application 121 verifies whether the first key data and the second key data match through the third signature value confirm_d_1 and the fourth signature value confirm_d_2, including steps 1110-1130 shown in fig. 11. Wherein the first key data comprises a first device key 1 and the second key data comprises a second device key 2.

Step 1110: signing by using the second equipment key to obtain a third signature value;

step 1120: acquiring a fourth signature value obtained by the Bluetooth equipment through signing based on the first equipment key;

step 1130: and if the third signature value is consistent with the fourth signature value, determining that the first key data is matched with the second key data.

Step 1110 and step 1120 are not performed sequentially.

As can be seen, the application 121 signs based on the second device key_key_2 to obtain a third signature value confirm_d_1. And the bluetooth device 110 signs based on the first device key_key_1, resulting in a fourth signature value confirm_d_2.

Wherein, for the plaintext of the third signature value confirm_d_1 corresponding to the fourth signature value confirm_d_2, optionally, a portion of the plaintext may be determined by the bluetooth device 110, for example, a portion of random_d2 of the plaintext is randomly generated by the bluetooth device 110. Alternatively, random_d2 may include 10 bytes. Another portion of the plaintext may be first authentication information oob _1 and second authentication information oob _2.

In this way, the bluetooth device 110 may send a portion of the plaintext range_d2 to the application 121, and then the bluetooth device and the application 121 locally generate the first authentication information oob _1 and the second authentication information oob _2 according to the methods described in the foregoing embodiments, respectively.

Thus, the Bluetooth device 110 is configured to determine, for range_d2 and first authentication information oob _1, plain text can be obtained random_d2|| oob _1. The application 121 may obtain plaintext random_a|| oob _2 for random_d2 and the second authentication information oob _2.

Alternatively, the signature algorithm used may be an HMAC algorithm and the hash function used in the signature algorithm may be a SHA256 algorithm. Of course, signature algorithms other than the HMAC algorithm, such as the ECDSA algorithm, may be used, and the application is not limited in this regard.

Thus, the bluetooth device 110 and the application 121 sign the same plaintext locally by using the same signing algorithm and key, and obtain the third signature value confirm_d_1 and the fourth signature value confirm_d_2, respectively. In the case where the third signature value confirm_d_1 is identical to the fourth signature value confirm_d_2, the application 121 may determine that the first device key device_key_1 is identical to the second device key_key_2. It may then be determined that the first key data matches the second key data and is valid.

In some embodiments, step 1010 is applied to a reconnection phase between the application 121 and the bluetooth device 110 after the replacement terminal logs in the application. The first key data includes a first identity key ir_key_1 and the second key data includes a second identity key ir_key_2. As such, step 1010 may include steps 1011-1014 as shown in FIG. 12.

Step 1011: responding to the encrypted message broadcast by the Bluetooth equipment, and sending a key request carrying the user identification of the application terminal to the service terminal;

wherein the encrypted message is broadcast when the Bluetooth device is first connected with the terminal device; the encrypted message is encrypted by using the first identity key;

the terminal device first connected to the bluetooth device 110 is different from the terminal device where the application terminal 121 is located when the application terminal 121 is bound to the bluetooth device 110.

In response to the encrypted message, the application 121 initiates a key request carrying the user identifier to the server 130. The user identifier may be an identifier corresponding to a user logging into the application terminal 121.

Step 1012: receiving second key data returned based on the key request;

because the server 130 pre-stores the mapping relation between the device information, the user identifier and the second key data, in response to the key request, the corresponding second key data can be determined according to the usage identifier and the mapping relation. The second key data is then returned to the application 121.

Step 1013: decrypting the encrypted message by using the second identity key;

the second key data returned by the server 130 at least includes a second identity key ir_key_2 and a second token key_key_2. In this way, the application 121 may decrypt the encrypted message using the second identity key ir_key_2.

Step 1014: and if the decryption is successful, determining that the Bluetooth device is a history binding device.

In the event that decryption is successful, bluetooth device 110 may be determined to be a history bound device. In this manner, the second token key_key_2 may be subsequently used for encrypted communication with the bluetooth device 110 at the application layer.

In some embodiments, step 1010 described above is applied to the connection phase between the bluetooth device 110 and the application 121. It is noted that the connection phase is different from the reconnection phase described above. The connection phase refers to that after the bluetooth device 110 and the application 121 complete binding and the communication is finished, the channel is re-established to communicate. At this time, the user does not change the terminal device to log on the application terminal 121.

After the binding is completed, the application 121 has stored the second key data and the communication address of the bluetooth device, for example, a bluetooth address. Thus, in the connection phase, the terminal device 120 can search for the bluetooth device 110 directly from the bluetooth address.

Thus, the above method may further comprise the steps of: and establishing communication connection with the Bluetooth equipment based on the communication address of the Bluetooth equipment.

In addition, the step 1010 may include: and reading pre-stored second key data corresponding to the Bluetooth equipment.

The read second key data includes at least a second token key_key_2, so that the application 121 performs encrypted communication with the bluetooth device 110 at the application layer by using the second token key_key_2 in a subsequent communication stage.

It is known that the communication phase can be entered for communication interaction after the binding phase, or after the reconnection phase, or after the connection phase. Wherein the first key data comprises a first token key_key_1 and the second key data comprises a second token key_key_2. Then in the communication phase, step 1020 described above includes the steps shown in fig. 13:

step 1021: generating a second session key based on the second token key;

Step 1022: authenticating the Bluetooth device by using the first session key and the second session key;

wherein the first session key is generated by the bluetooth device based on the first token key;

it is known that the bluetooth device 110 derives the first session key session_key_1 by using the first token key_key_1. The application 121 derives the second session key_key_2 by using the second token key_key_2. Subsequently, bluetooth device 110 may authenticate using the first session key_key_1 and the second session key_key_2. The authentication may be performed by means of a signature, for example.

The key derivation process and the authentication process may refer to the embodiment described in fig. 7, and are not described herein.

Step 1023: and in response to the authentication passing, carrying out encrypted communication with the application end at a Bluetooth application layer based on the first session key and the second session key.

In the case that the authentication is passed, the bluetooth device 110 and the application 121 may establish a session, and encrypt and decrypt the interaction data using the first session key session_key_1 and the second session key_2.

In addition, the application also provides a binding method and a communication method of the Bluetooth device, as shown in fig. 14-15.

In the Binding phase, in response to the Binding command < Start Binding > initiated by the application 121 (step S201), the bluetooth device 110 generates a first random number random_d1 (step S101). Subsequently, the bluetooth device 110 transmits the device information and the first random number random_d1 to the application 121 (step S102), and transmits the device information and the first random number random_d1 to the server 130 through the application 121 (step S202).

After receiving the data, the server 130 may generate a second temporary public-private key pair (pub_s_tk, pri_s_tk); generating a fifth signature sign_s by using the first random number random_d1, the second temporary public key pub_s_tk and the second long-term private key pri_s_ ltk of the local terminal; generating a second random number random_s; recording equipment information; and generates a binding identification bind_id (step S301-step S305). Wherein the binding identifier is used to identify the current binding. Subsequently, the server 130 may send the binding identifier bind_id, the second temporary public key pub_s_tk, the fifth signature sign_s, and the second random number random_s to the application 121 (step S306). The application 121 may send the second temporary public key pub_s_tk, the fifth signature sign_s and the second random number random_s to the bluetooth device 110 (step S203).

After the bluetooth device 110 receives the data, the fifth signature sign_s may be checked by using the second long-term public key pub_s_ ltk (step S103). In the case of authentication passing, bluetooth device 110 may determine that the identity of server 130 passes.

Thereafter, the bluetooth device 110 may continue to generate a first temporary public-private key pair (pub_d_tk, pri_d_tk); generating a first shared key share_key_1 based on the key agreement mechanism, the second temporary public key pub_s_tk, and the first temporary private key pri_d_tk; deriving a first derivative key determined_key_1 by using the first shared key_key_1; splitting the first derivative key derived_key_1 into three first sub-keys (including a first device key device_key_1, a first token key_key_1, and a first identity key ir_key_1), thereby obtaining first key data; and generating a sixth signature sign_d using the second random number random_s, the first temporary public key pub_d_tk, and the first long-term private key pri_d_ ltk of the home terminal ₁ (step S104-step S108).

Subsequently, the bluetooth device 110 may combine the first temporary public key pub_d_tk with the sixth signature sign_d ₁ To the application end 121 (step S109). The application 121 may combine the first temporary public key pubd tk carrying the binding identity bind id with the sixth signature sign d ₁ To the application end 121 (step S204).

After the server 130 receives the data, the first long-term public key pub_d_ ltk can be used to sign_d ₁ A label verification is performed (step S307). In the sixth signature sign_d ₁ In the case of authentication passing, the application 121 may determine that the identity of the bluetooth device 110 passes.

Thereafter, the server 130 may generate a second shared key share_key_2 based on the key negotiation mechanism, the first temporary public key pub_d_tk, and the second temporary private key pri_s_tk; deriving a second derived key_key_2 using the second shared key_key_2; splitting the second derivative key derived_key_2 into three second sub-keys (including a second device key device_key_2, a second token key_2, and a second identity key ir_key_2), thereby obtaining second key data; generating second authentication information oob _2 based on the first temporary public key pub_d_tk and the second temporary pub_s_tk; and generating a random string random_bind (step S308-step S312).

Subsequently, the server 130 may send the second key data, the second authentication information oob _2 and the random string random_bind to the application 121 (step S313).

After receiving the data, the application 121 may display the second verification information oob _2; generating a part of random_a of the first plaintext; the plaintext random_a|| oob _2 is generated by using a portion of the first plaintext random_a and the second authentication information oob _2, and the plaintext random_a|| oob _2 is signed by using the second device key_key_2 to obtain a second signature value confirm_a_2 (step S205-step S207).

Subsequently, the application 121 may send a portion of the first plaintext random_a, the second signature value confirm_a_2, and the random string random_bind to the bluetooth device 110 (step S208).

After receiving the data, the bluetooth device 110 may generate first authentication information oob _1 based on the first temporary public key pub_d_tk and the second temporary pub_s_tk; and generating plaintext random_a| oob _1 using a portion of the first plaintext random_a and the first authentication information oob _1, and signing the plaintext random_a| oob _1 using the first device key_key_1 to obtain a first signature value confirm_a_1, where the bluetooth device 110 may determine that the first key data and the second key data are valid if the first signature value confirm_a_1 and the second signature value confirm_a_2 are consistent (step S110-step S111).

Subsequently, the bluetooth device 110 may also display the first authentication information oob _1 and wait for the user to confirm. In response to the confirmation instruction input by the user, the bluetooth device 110 may generate a portion random_d2 of the second plaintext; generating a plaintext random_d2I oob _1 by using a part of the second plaintext random_d2 and the first verification information oob _1, and signing the plaintext random_d2I oob _1 by using the first device key_key_1 to obtain a fourth signature value confirm_d_2; and signing the random string random_bind with the first shared key share_key_1 to obtain a seventh signature bind_sign_1 (step S112-step S115).

Subsequently, the bluetooth device 110 may transmit a portion of the second plaintext, the fourth signature value confirm_d_2, and the seventh signature bind_sign_1 to the application 121 (step S116).

After the application end 121 receives the data, it generates a plaintext random_d2| oob _2 by using a portion of the second plaintext random_d2 and the second verification information oob _2, and signs the plaintext random_d2| oob _2 by using the second device key_2 to obtain a third signature value confirm_d_1, where the application end 121 can determine that the first key data and the second key data are valid when the third signature value confirm_d_1 is consistent with the fourth signature value confirm_d_2 (step S209).

Subsequently, the application 121 may send the binding identifier bind_id and the seventh signature bind_sign_1 to the server 130 (step S210).

After the server 130 receives the data, the second shared key share_key_2 may be used to sign the random string random_bind, to obtain an eighth signature bind_sign_2. In case the seventh signature bind_sign_1 is identical to the eighth signature bind_sign_2, communication security between the bluetooth device 110 and the server 130 may be determined (step S314). Subsequently, the server 130 may encrypt the binding data bound_data with the second device key_key_2 to obtain encrypted information encrypted_data_1 (step S315), and send the encrypted information encrypted_data_1 to the application 121 (step S316). The application 121 may forward the encrypted information encrypted_data_1 to the bluetooth device 110 (step S211).

The bluetooth device 110 may decrypt the encrypted information encrypted_data_1 using the second device key_key_1, and in case the decryption is successful, may notify the application 121 that the binding is successful (step S117-step S118). The application 121 may display a notification of successful binding (step S212). The binding phase between the bluetooth device 110 and the application 121 is completed.

In the communication phase, the application 121 generates a first random string rand_app and sends it to the bluetooth device 110 (step S213-step S214).

The bluetooth device 110 may generate a second random string rand_d; deriving a first session key session_key_1 by using the first token key_key_1; and forming a plaintext rand_app|rand_d from the first random string rand_app and the second random string rand_d, and signing the plaintext rand_app|rand_d by using the first session key_key_1 to obtain a ninth signature sign_d ₂ 1 (step S119 to step S121).

Subsequently, the bluetooth device 110 may compare the second random string rand_d with the ninth signature sign_d ₂ 1 is sent to the application terminal 121 (step S122).

After receiving the data, the application 121 may derive a second session key_key_2 by using the second token key_key_2; the first random character string rand_app and the second random character string rand_d form a plaintext rand_app|rand_d, and the plaintext rand_app|rand_d is signed by using a second session key_key_2 to obtain a tenth signature sign_d ₂ 2. In the ninth signature sign_d ₂ 1 and tenth signature sign_d ₂ If 2 is identical, it may be determined that the identity of the bluetooth device 110 and the application 121 pass (step S215-step S216).

Subsequently, the application 121 may encrypt the information deviceInfo with the second session key_key_2 to obtain encrypted data encrypted_data_2, and send the encrypted data encrypted_data_2 to the bluetooth device 110 (step S217-step S218). The bluetooth device 110 may decrypt using the first session key_key_1, and may further notify the application 121 that the session establishment is successful if the decryption is successful (step S123-step S124). After the session is established, the bluetooth device 110 and the application 121 may use the first session key_key_1 and the second session key_2 to encrypt and decrypt during data interaction. The communication phase is thus completed.

In addition, the fourth aspect of the application also provides a binding device applied to the Bluetooth equipment. The Bluetooth equipment communicates with the service end through the application end, and the application end is carried on the terminal equipment. As shown in fig. 16, the binding apparatus 1600 includes:

a first sending module 1610, configured to send device information of a home terminal to the server terminal;

A first key module 1620 configured to obtain first key data based on a key negotiation mechanism;

a first verification module 1630, configured to perform validity verification on the first key data and the second key data; the second key data is obtained by the server based on the key negotiation mechanism; the first key data and the second key data are used for the Bluetooth equipment to carry out encrypted communication with the application end;

a first confirmation module 1640, configured to confirm that the bluetooth device is successfully bound to the user identifier of the application end in response to receiving the confirmation information; and the confirmation information is sent after the equipment information, the user identification and the second key data are bound by the server based on the validity verification.

In addition, the fifth aspect of the present application provides a binding apparatus, which is applied to a server, where the server communicates with a bluetooth device through an application, and the application is carried on a terminal device. As shown in fig. 17, the binding apparatus 1700 includes:

a second obtaining module 1710, configured to obtain device information of the bluetooth device and a user identifier sent by the application end;

a second key module 1720 for deriving second key data based on a key agreement mechanism;

A second binding module 1530, configured to bind the device information, the user identifier, and the second key data to obtain a mapping relationship in response to determining that the first key data and the second key data are valid; wherein the first key data is obtained by the Bluetooth device based on the key negotiation mechanism; the first key data and the second key data are used for the Bluetooth equipment to carry out encrypted communication with the application end;

a second transmitting module 1740 for returning acknowledgement information to the bluetooth device.

In addition, the sixth aspect of the present application provides a bluetooth communication device, which is applied to an application terminal mounted on a terminal device, where the application terminal communicates with a server. As shown in fig. 18, the communication apparatus 1800 includes:

a third obtaining module 1810, configured to obtain second key data obtained by the server based on a key negotiation mechanism;

a third communication module 1820, configured to perform encrypted communication with the bluetooth device at a bluetooth application layer based on the first key data and the second key data;

The implementation process of the functions and roles of each module in the above device is specifically shown in the implementation process of the corresponding steps in the above method, and will not be described herein again.

Based on the binding method of the bluetooth device and the bluetooth communication method according to any of the embodiments, the application further provides a schematic structural diagram of an electronic device as shown in fig. 19. At the hardware level, as in fig. 19, the electronic device includes a processor, an internal bus, a network interface, a memory, and a nonvolatile memory, and may of course include hardware required by other services. The processor reads the corresponding computer program from the nonvolatile memory into the memory and then runs the computer program to implement a method for binding bluetooth devices or a method for bluetooth communication according to any of the embodiments described above.

In some embodiments, the electronic device may be a bluetooth device 110 to perform a method of binding bluetooth devices as described in the first aspect above.

In some embodiments, the electronic device may be the server 130 to perform a method for binding bluetooth devices as described in the second aspect above.

In some embodiments, the electronic device may be a terminal device 120, and the application terminal 121 on which the electronic device is mounted may perform a bluetooth communication method as described in the third aspect above.

The application also provides a computer storage medium storing a computer program which when executed by a processor is operable to perform a method of binding a bluetooth device or a method of bluetooth communication as described in any of the embodiments above.

In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. The apparatus embodiments described above are merely illustrative, for example, of the flowcharts and block diagrams in the figures that illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition, functional modules in the embodiments of the present application may be integrated together to form a single part, or each module may exist alone, or two or more modules may be integrated to form a single part.

The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The above description is only an example of the present application and is not intended to limit the scope of the present application, and various modifications and variations will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application. It should be noted that: like reference numerals and letters denote like items in the following figures, and thus once an item is defined in one figure, no further definition or explanation thereof is necessary in the following figures.

The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

It is noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

Claims

1. The binding method of the Bluetooth device is characterized by being applied to the Bluetooth device, wherein the Bluetooth device is communicated with a service end through an application end, and the application end is carried on terminal equipment; the method comprises the following steps:

obtaining first key data based on a key negotiation mechanism;

2. The method of claim 1, wherein the bluetooth device communicates with the terminal device in a bluetooth transport layer via a non-authentication mode.

3. The method of claim 1, wherein the validating the first key data and the second key data comprises:

Verifying whether the first key data matches the second key data;

and in the case of a match, determining that the first key data and the second key data are valid.

4. A method according to claim 3, wherein the first key data comprises a first device key and the second key data comprises a second device key; the verifying whether the first key data matches the second key data comprises:

signing by using the first equipment key to obtain a first signature value;

acquiring a second signature value obtained by the application terminal by signing based on the second equipment key;

and if the first signature value is consistent with the second signature value, determining that the first key data is matched with the second key data.

5. The method according to claim 1, wherein the method further comprises:

generating and outputting first verification information;

receiving a confirmation instruction input by a user based on the first verification information and the second verification information; the second verification information is generated by the server and output by the application end;

and determining the home terminal as the equipment to be bound based on the confirmation instruction.

6. The method of any of claims 1-5, wherein after confirming that the binding was successful, the method further comprises:

and carrying out encryption communication with the application end at a Bluetooth application layer based on the first key data and the second key data.

7. The method of claim 6, wherein the first key data comprises a first token key and the second key data comprises a second token key; the encrypting communication between the Bluetooth application layer and the application end based on the first key data and the second key data comprises the following steps:

generating a first session key based on the first token key;

the identity of the application terminal is verified by utilizing the first session key and the second session key; wherein the second session key is generated by the application based on the second token key;

and in response to the authentication passing, carrying out encrypted communication with the application end at a Bluetooth application layer based on the first session key and the second session key.

8. The method of claim 1, wherein the first key data comprises a first identity key and the second key data comprises a second identity key; after confirming that the binding was successful, the method further comprises:

9. The binding method of the Bluetooth equipment is characterized by being applied to a server, wherein the server communicates with the Bluetooth equipment through an application end, and the application end is carried on terminal equipment; the method comprises the following steps:

obtaining second key data based on a key negotiation mechanism;

And returning confirmation information to the Bluetooth equipment.

10. The method according to claim 9, wherein the method further comprises:

responding to the key request of the application end, and determining second key data corresponding to the user identification based on the mapping relation between the user identification carried by the key request and the user identification; the key request is initiated when the terminal equipment is connected with the Bluetooth equipment for the first time;

and returning the second key data to the application end so that the application end can carry out encrypted communication with the Bluetooth equipment based on the second key data.

11. The Bluetooth communication method is characterized by being applied to an application end mounted on terminal equipment, wherein the application end communicates with a server end; the method comprises the following steps:

based on the first key data and the second key data, carrying out encrypted communication with the Bluetooth device at the Bluetooth application layer;

12. The method of claim 11, wherein the obtaining the second key data obtained by the server based on a key negotiation mechanism includes:

In the binding stage of the Bluetooth device, second key data sent by the server side are obtained;

the binding phase further comprises the steps of:

and verifying the validity of the first key data and the second key data.

13. The method of claim 12, wherein in the binding phase, the bluetooth device communicates with the terminal device in a bluetooth transport layer via a non-authentication mode.

14. The method of claim 12, wherein the validating the first key data and the second key data comprises:

verifying whether the first key data matches the second key data;

15. The method of claim 14, wherein the first key data comprises a first device key and the second key data comprises a second device key; the verifying whether the first key data matches the second key data comprises:

signing by using the second equipment key to obtain a third signature value;

Acquiring a fourth signature value obtained by the Bluetooth equipment through signing based on the first equipment key;

and if the third signature value is consistent with the fourth signature value, determining that the first key data is matched with the second key data.

16. The method of claim 11, wherein the first key data comprises a first identity key and the second key data comprises a second identity key; the obtaining the second key data obtained by the server based on the key negotiation mechanism includes:

responding to the encrypted message broadcast by the Bluetooth equipment, and sending a key request carrying the user identification of the application terminal to the service terminal;

receiving second key data returned based on the key request;

decrypting the encrypted message by using the second identity key;

and if the decryption is successful, determining that the Bluetooth device is a history binding device.

17. The method of claim 11, wherein the method further comprises:

Establishing communication connection with the Bluetooth equipment based on the communication address of the Bluetooth equipment;

the obtaining the second key data obtained by the server based on the key negotiation mechanism includes:

and reading pre-stored second key data corresponding to the Bluetooth equipment.

18. The method of any of claims 11-17, wherein the first key data comprises a first token key and the second key data comprises a second token key; the encrypting communication with the Bluetooth device at the Bluetooth application layer based on the first key data and the second key data comprises the following steps:

generating a second session key based on the second token key;

authenticating the Bluetooth device by using the first session key and the second session key; wherein the first session key is generated by the bluetooth device based on the first token key;

19. The binding device is characterized by being applied to Bluetooth equipment, wherein the Bluetooth equipment communicates with a service end through an application end, and the application end is carried on terminal equipment; the device comprises:

20. The binding device is characterized by being applied to a server, wherein the server communicates with the Bluetooth equipment through an application end, and the application end is carried on terminal equipment; the device comprises:

21. The Bluetooth communication device is characterized by being applied to an application end mounted on terminal equipment, wherein the application end communicates with a server end; the device comprises:

22. An electronic device, the electronic device comprising:

a processor;

a memory for storing processor-executable instructions;

wherein the processor, when invoking the executable instructions, performs the operations of the method of any of claims 1-8, or 9-10, or 11-18.

23. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the method of any of claims 1-8, or 9-10, or 11-18.