A data transmission method, electronic equipment, storage medium and computer program product

Abstract

This application provides a data transmission method, electronic device, storage medium, and computer program product, relating to the field of communication technology. It enables the acquisition of an encryption key without Bluetooth pairing and the transmission of data with other trusted electronic devices based on that encryption key, simplifying the data transmission process between electronic devices. The method includes: acquiring an encryption key; scanning Bluetooth devices within a first range to obtain available devices, including a second electronic device storing the encryption key, the second electronic device being unpaired with a first electronic device, and the two devices having a trusted relationship; encrypting communication data based on the encryption key, the communication data being data transmitted between the first and second electronic devices via Bluetooth communication.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a data transmission method, electronic device, storage medium, and computer program product. Background Technology

[0002] Electronic devices are generally equipped with Bluetooth functionality; these devices are called Bluetooth devices. Currently, two Bluetooth devices need to be paired before establishing a Bluetooth connection. During the pairing process, the Bluetooth devices can exchange keys to enable encrypted data transmission during subsequent communication, ensuring the security of data transmission.

[0003] However, with the rapid popularization of Bluetooth devices and the improvement of people's living standards, more and more users own a large number of Bluetooth devices. If users want their multiple Bluetooth devices to establish Bluetooth connections between each other, they need to manually operate the pairing process between any two Bluetooth devices. The whole operation is cumbersome and affects the user experience. Summary of the Invention

[0004] This application provides a data transmission method, an electronic device, a storage medium, and a computer program product. The electronic device can obtain an encryption key without Bluetooth pairing and transmit data with other trusted electronic devices based on the encryption key, which can simplify the data transmission process between electronic devices and improve the user experience.

[0005] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0006] In a first aspect, embodiments of this application provide a data transmission method applicable to a first electronic device. Specifically, the first electronic device can acquire an encryption key; scan Bluetooth devices within a first range to obtain available devices, which may include a second electronic device storing the aforementioned encryption key. The second electronic device is in an unpaired state with the first electronic device, and the two devices have a trusted relationship. Communication data is encrypted based on the encryption key, and this communication data is data transmitted between the first and second electronic devices via Bluetooth communication.

[0007] In this way, the first electronic device can obtain the encryption key without Bluetooth pairing with the second electronic device. Furthermore, when the second electronic device has a trusted relationship with it and is within its Bluetooth communication range, the first electronic device can directly transmit data using the obtained encryption key. That is, the second electronic device can share the same encryption key with the first electronic device to transmit data without needing to perform a Bluetooth pairing process to exchange keys. Thus, when a user owns a large number of electronic devices, the data transmission method provided in this application embodiment simplifies the process of transmitting data between multiple electronic devices, thereby improving the user experience.

[0008] In conjunction with the first aspect, in one possible implementation, obtaining the encryption key may include: obtaining the encryption key in response to establishing a trusted relationship with a third electronic device, wherein the encryption key is stored in the third electronic device.

[0009] Understandably, the first electronic device can obtain the encryption key from elsewhere (e.g., from other electronic devices or a cloud server). Taking the example of the first electronic device obtaining the encryption key from another electronic device (e.g., a third electronic device), the first electronic device needs to have a trusted relationship with the third electronic device to obtain the shared encryption key. Thus, the first electronic device can obtain the encryption key in response to establishing a trusted relationship with the third electronic device. By sharing the encryption key with other electronic devices based on a trusted relationship, the encryption key acquisition process is simplified, thereby further simplifying the data transmission process between different electronic devices. Simultaneously, by sharing the key with electronic devices with whom a trusted relationship has been established, the security of the encryption key sharing process can be ensured.

[0010] In conjunction with the first aspect, in one possible implementation, the above-mentioned response to establishing a trusted relationship with a third electronic device and obtaining an encryption key may include: receiving an encryption key sent by a cloud server in response to logging into the same identity account as the third electronic device.

[0011] The first electronic device can establish a trusted relationship with the third electronic device by logging into the same identity account, thereby obtaining the encryption key. With the first electronic device logged into the identity account, it can obtain the encryption key sent by the cloud server via cloud synchronization, or it can obtain the encryption key from the third electronic device. Compared to obtaining the encryption key from the third electronic device, receiving the encryption key sent by the cloud server is more convenient and speeds up the encryption key acquisition process when the first electronic device is logged into the identity account.

[0012] In conjunction with the first aspect, in one possible implementation, the above-mentioned response to establishing a trusted relationship with a third electronic device and obtaining an encryption key may further include: in response to completing identity authentication with the third electronic device, receiving an encryption key sent by the third electronic device.

[0013] In this process, the first electronic device can establish a trusted relationship with the third electronic device by completing identity authentication. Specifically, the first electronic device and the third electronic device can build a trusted relationship by establishing a trusted link and completing identity authentication during the trusted link establishment process. In this way, the third electronic device can share the encryption key with the first electronic device based on the trusted relationship, thus ensuring the security of the shared encryption key.

[0014] In conjunction with the first aspect, in one possible implementation, obtaining the encryption key may further include: generating an encryption key after logging into the identity account, and associating the encryption key with the identity account.

[0015] Understandably, the first electronic device can obtain the encryption key, or it can generate it itself. Specifically, if the first electronic device is logged into an account, it can generate an encryption key based on that account, thus associating the obtained encryption key with the account. By directly generating the encryption key based on the account, without needing to perform a separate Bluetooth pairing process, the flexibility and intelligence of obtaining the encryption key can be improved.

[0016] In conjunction with the first aspect, in one possible implementation, the generation of the encryption key may include: generating the encryption key when no encryption key associated with the aforementioned identity account exists.

[0017] Before generating the encryption key, it can be determined whether there is an encryption key associated with the aforementioned identity account. The encryption key is only generated if it is determined that there is no encryption key associated with the aforementioned identity account. This can avoid generating the same encryption key repeatedly and save device processing resources.

[0018] In conjunction with the first aspect, in one possible implementation, before generating the encryption key as described above, the method may further include: querying whether an encryption key associated with the aforementioned identity account is stored; in response to not finding an encryption key associated with the aforementioned identity account, sending an encryption key query request to the cloud server; and determining, based on the query result returned by the cloud server, that no encryption key associated with the aforementioned identity account exists.

[0019] Before generating an encryption key, the first electronic device can first check whether an encryption key associated with the aforementioned identity account is stored locally. If no encryption key associated with the aforementioned identity account is stored locally, it can then check whether an encryption key associated with the aforementioned identity account is stored on the cloud server. In this way, an encryption key can be generated only when neither the local device nor the cloud server stores an encryption key associated with the aforementioned identity account, which can more accurately avoid generating the same encryption key repeatedly.

[0020] In conjunction with the first aspect, in one possible implementation, before generating the encryption key as described above, the method may further include: querying whether an encryption key associated with the aforementioned identity account is stored; in response to not finding an encryption key associated with the aforementioned identity account, determining whether an encryption key associated with the aforementioned identity account has been received within a first time period starting from logging into the aforementioned identity account; in response to not receiving an encryption key associated with the aforementioned identity account within the first time period starting from logging into the aforementioned identity account, determining that no encryption key associated with the aforementioned identity account exists.

[0021] Before generating the encryption key, the first electronic device can first check if an encryption key associated with the aforementioned identity account is stored locally. If no encryption key associated with the aforementioned identity account is stored locally, it can continue to wait for a first period of time since logging into the identity account to determine whether the encryption key associated with the aforementioned identity account has been received. If the encryption key associated with the aforementioned identity account is not received within the first period of waiting, it means that an encryption key associated with the aforementioned identity account does not exist, and it can be determined that no encryption key associated with the aforementioned identity account exists. By using multiple checks to determine whether an encryption key associated with the aforementioned identity account is stored, the timing of encryption key generation can be determined more accurately.

[0022] In conjunction with the first aspect, in one possible implementation, the above-mentioned generation of encryption keys may include: generating encryption keys based on at least one of the aforementioned identity account and device information of the first electronic device using a preset encryption algorithm.

[0023] When an account is logged in, the following methods can be used: A preset encryption algorithm can be employed to generate an encryption key solely based on the account information, with the encryption key associated with the account; alternatively, an encryption key can be generated solely based on the device information of the first electronic device, with the encryption key associated with the device information of the first electronic device; or an encryption key can be generated based on both the account information and the device information of the first electronic device, with the encryption key associated with both. This allows for flexible generation of encryption keys when an account is logged in.

[0024] In conjunction with the first aspect, in one possible implementation, the generation of the encryption key may include: generating an encryption key based on the device information of the first electronic device at a first moment, wherein the encryption key is associated with the device information of the first electronic device, and the first moment may be when the first electronic device is factory-set, when the first electronic device is activated, or when the first electronic device is upgraded.

[0025] In cases where the first electronic device is not logged into an account, an encryption key can be generated based on the device information of the first electronic device. Understandably, to avoid data redundancy, the encryption key can be generated only at specific times based on the device information of the first electronic device. For example, it can be generated during the factory setup of the first electronic device, when the first electronic device is activated (for the first time), or when the first electronic device is upgraded. In this way, the timing of encryption key generation can be flexibly determined even when the first electronic device is not logged into an account, while avoiding data redundancy caused by generating encryption keys multiple times for the same device.

[0026] In conjunction with the first aspect, in one possible implementation, the method may further include: in response to establishing a trusted relationship with the fourth electronic device, sending an encryption key and an identifier of the encryption key to the fourth electronic device.

[0027] In this method, the first electronic device can share an encryption key with a fourth electronic device that does not store the encryption key itself, and then transmit data based on the shared encryption key. In this approach, the first electronic device can first establish a trusted relationship with the fourth electronic device, and then send the encryption key and its identifier to the fourth electronic device based on this trusted relationship. This improves the convenience of data transmission, and by sending the encryption key identifier to the fourth electronic device, it is easier for the fourth electronic device to accurately identify the encryption key used to transmit data with the first electronic device.

[0028] In conjunction with the first aspect, in one possible implementation, the method may further include: after logging into the identity account, sending an encryption key and an identifier of the encryption key to the cloud server.

[0029] By sending the generated encryption key and its identifier to the cloud server, it is possible to back up the encryption key and retrieve it if local data is lost. On the other hand, it is also possible to synchronize (share) the encryption key with other trusted electronic devices through cloud synchronization.

[0030] In conjunction with the first aspect, in one possible implementation, prior to encrypting the communication data based on the encryption key, the method may further include: displaying a first interface, the first interface including a second electronic device and a trusted identifier of the second electronic device, the trusted identifier of the second electronic device indicating that the second electronic device is a trusted device of the first electronic device. In this manner, encrypting the communication data based on the encryption key may include: encrypting the communication data based on the encryption key in response to a user's selection of the second electronic device.

[0031] By displaying the trusted identifier of the second electronic device, users can easily and intuitively identify trusted devices in the available list of the first electronic device. Compared to electronic devices that require establishing a trusted relationship before being identified as devices to be connected, this can improve the efficiency of identifying devices to be connected.

[0032] In conjunction with the first aspect, in one possible implementation, the aforementioned available device may further include a fifth electronic device. In this manner, the aforementioned encryption of communication data based on the encryption key may include: encrypting communication data based on the encryption key when the first distance is less than the second distance, wherein the first distance is the distance between the second electronic device and the first electronic device, and the second distance is the distance between the fifth electronic device and the first electronic device.

[0033] If the fifth electronic device stores an encryption key and has a trusted relationship with the first electronic device, the first electronic device can encrypt communication data based on the encryption key when it is closest to the fifth electronic device. By determining the data transmission target based on distance, the stability and effectiveness of data transmission can be ensured.

[0034] In conjunction with the first aspect, in one possible implementation, before encrypting the communication data based on the encryption key, the method may further include: establishing an asynchronous connectionless connection with a second electronic device; and sending a data transmission instruction to the second electronic device, the data transmission instruction carrying an identifier of the encryption key.

[0035] If the second electronic device obtains the encryption key from elsewhere, and the first electronic device and the second electronic device are indirectly trusted, in order to ensure accurate data transmission with the second electronic device, the first electronic device can send an identifier data transmission instruction carrying the encryption key to the second electronic device, so as to instruct the second electronic device to use the encryption key carrying the identifier to transmit data with it, thereby improving the accuracy of data transmission.

[0036] In conjunction with the first aspect, in one possible implementation, the aforementioned encryption key may include multiple keys with different security modes. The aforementioned data transmission instruction may also carry a target security mode, which is a security mode corresponding to the encryption security requirements when the first electronic device and the second electronic device transmit data. In this manner, before encrypting the communication data based on the encryption key, the method may further include: determining the target security mode used when transmitting data with the second electronic device; determining a target key based on the aforementioned identifier and the target security mode; furthermore, in this manner, encrypting the communication data based on the encryption key may include: encrypting the communication data based on the target key.

[0037] Specifically, by determining the corresponding security mode based on the encryption security requirements when transmitting data, and then determining the encryption key for transmitting data based on the security mode and the aforementioned identifier, the encryption key can be determined in a targeted manner, thereby improving the accuracy of data transmission.

[0038] In conjunction with the first aspect, in one possible implementation, the aforementioned encryption key may include multiple different types of keys, and the aforementioned data transmission instruction may also carry a key type. Thus, before encrypting communication data based on the encryption key, the method may further include: determining a target key according to the aforementioned identifier and key type. In this manner, the aforementioned encryption of communication data based on the encryption key may include: encrypting communication data based on the target key.

[0039] It is understandable that different communication scenarios for transmitting data may require different types of encryption keys. Thus, the encryption key can be determined more accurately based on the key type and the aforementioned identifier, thereby improving the accuracy of data transmission.

[0040] In conjunction with the first aspect, in one possible implementation, the aforementioned different types of keys can include keys for Bluetooth standard pairing scenarios and keys for BLE mesh networking scenarios. Determining the key type based on the communication scenario can improve the efficiency of data transmission.

[0041] In conjunction with the first aspect, in one possible implementation, the aforementioned identifier is the identity account associated with the encryption key and / or the device information associated with the encryption key. By using the identity account and / or device information as the identifier for the encryption key, the process of obtaining the encryption key can be simplified, thereby simplifying the overall data transmission process.

[0042] Secondly, embodiments of this application provide a data transmission method applicable to a network system, which includes a first electronic device, a second electronic device, and a third electronic device. The method includes: the first electronic device acquiring an encryption key; the first electronic device establishing a trusted relationship with the second electronic device and sending the encryption key to the second electronic device; the first electronic device transmitting data to the second electronic device based on the encryption key in response to detecting the second electronic device; the first electronic device establishing a trusted relationship with the third electronic device and sending the encryption key to the third electronic device; and the third electronic device transmitting data to the second electronic device based on the encryption key in response to detecting the second electronic device.

[0043] In this system, the first electronic device can share the encryption key with a second electronic device with which it has a trusted relationship, and it can also share the encryption key with a third electronic device with which it has a trusted relationship. In this way, multiple mutually trusted electronic devices can directly use the shared (same) encryption key to transmit data between each other without having to perform a pairing action separately, which simplifies the process of obtaining the encryption key and the overall process of data transmission.

[0044] In addition, the first electronic device can transmit data with its directly trusted electronic device based on an encryption key, and the third electronic device can transmit data with its indirectly trusted second electronic device based on an encryption key. This improves the flexibility and convenience of data transmission and enhances the user experience.

[0045] Thirdly, embodiments of this application provide an electronic device, which includes a memory and one or more processors; wherein the memory is coupled to one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and when one or more processors execute the computer instructions, the electronic device performs the method described in the first or second aspect above.

[0046] Fourthly, embodiments of this application provide a computer storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the methods described in the first or second aspect above.

[0047] Fifthly, embodiments of this application provide a computer program product that, when run on a computer, causes the computer to perform the methods described in the first or second aspect above. Attached Figure Description

[0048] Figure 1 This is a scenario diagram illustrating Bluetooth pairing between multiple electronic devices, provided as an embodiment of this application.

[0049] Figure 2An example diagram of a Bluetooth settings interface for an electronic device provided in an embodiment of this application;

[0050] Figure 3 A schematic diagram of the architecture of a network system provided in an embodiment of this application;

[0051] Figure 4 This is a schematic diagram of another network system architecture provided in an embodiment of this application;

[0052] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0053] Figure 6 A flowchart illustrating a data transmission method provided in an embodiment of this application;

[0054] Figure 7 A flowchart illustrating another data transmission method provided in this application embodiment;

[0055] Figure 8 A flowchart illustrating yet another data transmission method provided in this application embodiment;

[0056] Figure 9 A flowchart illustrating another data transmission method provided in this application embodiment;

[0057] Figure 10 A flowchart illustrating another data transmission method provided in an embodiment of this application. Detailed Implementation

[0058] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. In the description of the embodiments of this application, unless otherwise stated, "at least one" refers to one or more, and "more than" refers to two or more. Furthermore, to facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first," "second," etc., are used in the embodiments of this application to distinguish identical or similar items with essentially the same function and effect. Those skilled in the art will understand that the terms "first," "second," etc., do not limit the quantity or execution order, and that "first," "second," etc., do not necessarily imply differences. It should also be understood that the term "and / or" is used to describe the relationship between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0059] In the embodiments described herein, references to "one embodiment" or "some embodiments" mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of the embodiments of this application, do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. The term "connection" includes both direct and indirect connections, unless otherwise stated.

[0060] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0061] In conventional technology, if a user owns multiple Bluetooth-enabled electronic devices and wants these devices to establish Bluetooth connections between each other, the user can manually pair the devices one by one. During the Bluetooth pairing process, the electronic devices can generate a key, which can be used by the devices to encrypt or decrypt data during subsequent data transmission, thus achieving encrypted data transmission and ensuring data security.

[0062] Please see Figure 1 , Figure 1 This illustration depicts a scenario where multiple electronic devices pair up via Bluetooth, as provided in an embodiment of this application. Figure 1 As shown, multiple electronic devices include a mobile phone 101, earphones 102, and a tablet computer 103. If a user wants any two of the mobile phone 101, earphones 102, and tablet computer 103 to establish a Bluetooth connection, there are at least three steps: first, control the mobile phone 101 and earphones 102 to pair via Bluetooth; then, control the mobile phone 101 and tablet computer 103 to pair via Bluetooth; and finally, control the earphones 102 and tablet computer 103 to pair via Bluetooth.

[0063] The Bluetooth pairing process between electronic devices requires user intervention. The following example uses mobile phone 101 and tablet computer 103, along with the attached diagram. Figure 2 This section describes the process of a user pairing electronic devices via Bluetooth.

[0064] When the Bluetooth function of mobile phone 101 is turned on, it can automatically search for available devices within its Bluetooth communication range. At this time, if the Bluetooth function of tablet computer 103 is also turned on and tablet computer 103 is within the Bluetooth communication range of mobile phone 101, then mobile phone 101 can search for tablet computer 103 and identify tablet computer 103 as an available device.

[0065] For example, Figure 2 The Bluetooth settings interface 201 of mobile phone 101 is shown. (For example...) Figure 2 As shown, the Bluetooth settings interface 201 includes a device list 2011 and a paired device list 2012. The device list 2011 can be used to display the names of available devices found by the mobile phone 101, such as the name of the tablet 103 (e.g., "b" 20111). Optionally, the device list 2011 may also include the names of other available devices found by the mobile phone 101, such as "c", "d", etc. Furthermore, the device list 2011 can also display the number of available devices found by the mobile phone 101 (e.g., 8).

[0066] The paired device list 2012 can be used to display the names of electronic devices that have been paired with the mobile phone 101. For example, the paired device list 2012 includes the names of devices that have been paired, such as "Device 1" and "Device 2".

[0067] The device names displayed in the paired device list 2012 can change as more or fewer devices are paired with the phone 101. For example, when... Figure 2 When the mobile phone 101 and the tablet computer 103 are paired, the name of the tablet computer 103 can be displayed in the list of paired devices 2012.

[0068] Optionally, the Bluetooth settings interface 201 may also include the name of the mobile phone 101 (e.g., "Xiao A"), and the name of the mobile phone 101 is not specifically limited here.

[0069] Furthermore, the mobile phone 101 can receive the user's action of selecting a device to be paired in the device list 2011. In response to this action, the mobile phone 101 can display a Bluetooth pairing window 2013 in the Bluetooth settings interface 201. For example, taking the user selecting a tablet computer 103 as the device to be paired as an example... Figure 2 As shown, mobile phone 101 can receive the user's click on the "b" icon 20111, and in response to this operation, mobile phone 101 can display... Figure 2 The Bluetooth pairing window shown is from 2013.

[0070] like Figure 2As shown, the Bluetooth pairing window 2013 includes a "Cancel" option 204, a "Pair" option 205, and an authorization option 206. Among them, the mobile phone 101 can receive the operation of the user clicking the "Cancel" option. In response to this operation, the mobile phone 101 can cancel the display of the Bluetooth pairing window 2013 as shown Figure 2 below. Alternatively, the mobile phone 101 can receive the operation of the user clicking the "Pair" option. In response to this operation, the mobile phone 101 sends a Bluetooth pairing request to the tablet computer 103, and after completing the Bluetooth pairing with the tablet computer 103, the mobile phone 101 can display the name of the tablet computer 103 in the paired device list 2012. For example, as shown Figure 2 below, after the mobile phone 101 completes the Bluetooth pairing with the tablet computer 103, it can display the name "Xiaob" 20111 of the tablet computer 103 in the paired device list 2012.

[0071] It should be noted that after the tablet computer 103 receives the Bluetooth pairing request sent by the mobile phone 101, it can provide a confirmation option or a cancellation option for the user to choose. Among them, in response to the user's operation on the confirmation option, the tablet computer 103 pairs with the mobile phone 101 via Bluetooth; or in response to the user's operation on the cancellation option, the tablet computer 103 does not pair with the mobile phone 101 via Bluetooth.

[0072] It should also be noted that when the mobile phone 101 receives the operation of the user clicking the "Pair" option 205, the above-mentioned "Authorization" option 206 can be in a selected state or an unselected state. Among them, when the "Authorization" option 206 is in the selected state, the mobile phone 101 grants the tablet computer 103 the permission to access its address book and call records, so that after the mobile phone 101 and the tablet computer 103 complete the Bluetooth pairing, the tablet computer 103 can access the address book and call records of the mobile phone 101. When the "Authorization" option 206 is in the unselected state, the mobile phone 101 does not grant the tablet computer 103 the permission to access its address book and call records. In this way, after the mobile phone 101 and the tablet computer 103 complete the Bluetooth pairing, the tablet computer 103 cannot access the address book and call records of the mobile phone 101.

[0073] It can be seen that the process of Bluetooth pairing involves many user operations and is rather cumbersome. Thus, when the user has a large number of electronic devices and wants to transfer data between different devices via the Bluetooth function, it will cause the user to frequently perform Bluetooth pairing operations, resulting in a cumbersome data transfer operation process between different devices, thereby reducing the efficiency and convenience of data transfer between devices; at the same time, it greatly affects the user operation experience.

[0074] To at least solve the above problems, the embodiment of the present application provides a data transfer method, which can be applied to Figure 3 and Figure 4 The network system shown.

[0075] Please see Figure 3 This illustration shows a schematic diagram of the architecture of a network system 10 provided in an embodiment of this application, applicable to the aforementioned data transmission method. For example... Figure 3 As shown, the network system 10 includes electronic device 100, electronic device 200 and electronic device 300.

[0076] Electronic device 100 is communicatively connected to electronic devices 200 and 300 respectively, and electronic devices 200 and 300 are communicatively connected. The communication connection methods include, but are not limited to, wireless network communication technology (Wireless Fidelity, WiFi), Bluetooth technology (including classic Bluetooth (Basic Rate (BR) / Enhanced Data Rate (EDR)) and Bluetooth Low Energy (BLE)), as well as 2G / 3G / 4G / 5G and other mobile communication technologies (mobile networks).

[0077] Specifically, electronic devices 100, 200, and 300 can be Bluetooth-enabled terminal devices such as mobile phones, tablets, laptops, ultra-mobile personal computers (UMPCs), desktop computers, laptops, handheld computers, netbooks, and personal digital assistants (PDAs), or Bluetooth-enabled terminal peripheral devices such as (Bluetooth) headsets, smartwatches, wristbands, speakers, Bluetooth styluses, and Bluetooth keyboards. This application does not impose any limitations on the type or specific form of the various electronic devices.

[0078] For example, in one embodiment, electronic device 100 can be a mobile phone (referred to as mobile phone 1 for easy distinction), electronic device 200 can be a mobile phone (referred to as mobile phone 2 for easy distinction), and electronic device 300 can be a peripheral device such as a Bluetooth headset. In another embodiment, electronic device 100 can be a mobile phone (referred to as mobile phone 1), electronic device 200 can be a mobile phone (referred to as mobile phone 2), and electronic device 300 can be a tablet. In yet another embodiment, electronic device 100 can be a mobile phone, electronic device 200 can be a watch, and electronic device 300 can be a Bluetooth headset. In yet another embodiment, electronic device 100 can be a watch, electronic device 200 can be a Bluetooth headset (referred to as headset 1), and electronic device 300 can be a Bluetooth headset (referred to as headset 2).

[0079] Please see Figure 4 This illustration shows a schematic diagram of the architecture of another network system 20 provided in an embodiment of this application, applicable to the above-described data transmission method. (Comparison) Figure 4 and Figure 3 It can be seen that, Figure 4 The network system 20 shown is Figure 3 The network system 10 shown has a similar structure, the difference being that the network system 20 also includes a cloud server 400. Electronic devices 100, 200, and 300 are connected to the cloud server 400 via mobile communication technologies such as 2G / 3G / 4G / 5G.

[0080] The cloud server 400 can be a standalone server, a server cluster, or a network center server; no specific restrictions are imposed here.

[0081] It should be noted that the types and quantities of electronic devices listed in the above network scenarios are merely examples and do not constitute a limitation on the embodiments of this application. For example, the number of electronic devices included in the network scenarios of this application embodiments may be four or more, which will not be listed here.

[0082] The data transmission method provided in this application includes: a first electronic device acquiring an encryption key; the first electronic device scanning Bluetooth devices within a first range to obtain available devices, including a second electronic device storing the encryption key, the second electronic device being in an unpaired state with the first electronic device, and the second electronic device having a trusted relationship with the first electronic device; the first electronic device encrypting communication data based on the encryption key, the communication data being data transmitted between the first and second electronic devices via Bluetooth communication. Thus, the first electronic device can obtain the encryption key without Bluetooth pairing and transmit data with the trusted second electronic device based on the encryption key, simplifying the data transmission process between electronic devices, improving the data transmission efficiency between different electronic devices, and enhancing the user experience.

[0083] The electronic devices involved in the embodiments of this application will be described in detail below.

[0084] In some embodiments, please refer to Figure 5 This illustration shows a structural diagram of an electronic device provided in an embodiment of this application. It should be noted that this electronic device may refer to the aforementioned electronic device 100, electronic device 200, or electronic device 300. It is understood that the structure illustrated in this embodiment does not constitute a specific limitation on electronic device 100, electronic device 200, or electronic device 300. In other embodiments, electronic device 100, electronic device 200, or electronic device 300 may include... Figure 5It may contain more or fewer components, or combine some components, or separate some components, or arrange the components differently. The components shown in the diagram may be implemented in hardware, software, or a combination of software and hardware.

[0085] like Figure 5 As shown, the electronic device 200 provided in this application embodiment may include: a processor 210, an external memory interface 220, an internal memory 221, a universal serial bus (USB) interface 230, a charging management module 240, a power management module 241, a battery 242, an antenna 250, a wireless communication module 260, an audio module 270, a speaker 270A, a receiver 270B, a microphone 270C, a headphone jack 270D, a sensor module 280, buttons 290, a motor 291, an indicator 292, a camera 293, and a display screen 294, etc.

[0086] The aforementioned sensor module 280 may include sensors such as pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, and bone conduction sensors.

[0087] Processor 210 may include one or more processing units, such as application processor (AP), modem processor, graphics processing unit (GPU), image signal processor (ISP), controller, memory, video codec, digital signal processor (DSP), baseband processor, and / or neural network processing unit (NPU). Different processing units may be independent devices or integrated into one or more processors.

[0088] A controller can be the nerve center and command center of an electronic device. Based on the instruction opcode and timing signals, the controller generates operation control signals to control the fetching and execution of instructions.

[0089] The processor 210 may also include a memory for storing instructions and data. In some embodiments, the memory in the processor 210 is a cache memory. This memory can store instructions or data that the processor 210 has just used or that are used repeatedly. If the processor 210 needs to use the instruction or data again, it can directly retrieve it from the memory. This avoids repeated accesses, reduces the waiting time of the processor 210, and thus improves system efficiency. The memory may also include non-volatile memory, such as one or more disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. The memory can store an operating system, such as uCOS, VxWorks, RTLinux, or other embedded operating systems.

[0090] In some embodiments, the processor 210 may include one or more interfaces. Interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0091] It is understood that the interface connection relationships between the modules illustrated in this embodiment are merely illustrative and do not constitute a structural limitation on the electronic device. In other embodiments, the electronic device may also employ different interface connection methods or combinations of multiple interface connection methods as described in the above embodiments.

[0092] The wireless communication function of an electronic device can be implemented through an antenna 250, a wireless communication module 260, a modem processor, and a baseband processor. In some embodiments, the antenna 250 and the wireless communication module 260 are coupled, enabling the electronic device to communicate with networks and other devices via wireless communication technology.

[0093] Antenna 250 is used to transmit and receive electromagnetic wave signals. Each antenna 250 in an electronic device can be used to cover one or more communication frequency bands. Different antennas 250 can also be reused to improve the utilization of antenna 250. For example, antenna 250 can be reused as a diversity antenna 250 for a wireless local area network. In some other embodiments, antenna 250 can be used in conjunction with a tuning switch.

[0094] The wireless communication module 260 can provide solutions for wireless communication applications in electronic devices, including WLAN (such as wireless fidelity, Wi-Fi) networks, Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR) technology, and other wireless communication technologies.

[0095] The wireless communication module 260 can be one or more devices integrating at least one communication processing module. The wireless communication module 260 receives electromagnetic waves via antenna 250, performs frequency modulation and filtering of the electromagnetic wave signal, and sends the processed signal to processor 210. The wireless communication module 260 can also receive signals to be transmitted from processor 210, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 250.

[0096] The external storage interface 220 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device. The external memory card communicates with the processor 210 through the external storage interface 220 to perform data storage functions. For example, music, video, and other files can be saved on the external memory card.

[0097] Internal memory 221 can be used to store computer executable program code, which includes instructions. Processor 210 executes various functional applications and data processing of the electronic device by running the instructions stored in internal memory 221. For example, in this embodiment, processor 210 can execute instructions stored in internal memory 221, which may include a program storage area and a data storage area.

[0098] The program storage area can store the operating system, at least one application program required for a function (such as audio playback, data transfer, etc.). The data storage area can store data created during the use of the electronic device (such as audio file data, voice call data, etc.). Furthermore, the internal memory 221 can include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0099] Optionally, if the electronic device 200 is a headset, speaker, or keyboard, the electronic device 200 may not include a display screen 294; if the electronic device 200 is a mobile phone, tablet, or watch, the electronic device 200 may not include a display screen 294.

[0100] The data transmission method provided in the embodiments of this application will be described below with reference to the accompanying drawings.

[0101] exist Figure 3 or Figure 4 In the scenario shown, electronic devices 100, 200, and 300 can establish a trusted relationship and share an encryption key after establishing the trusted relationship. Specifically, the two electronic devices that establish a trusted relationship are each other's trusted devices.

[0102] In this application embodiment, there are multiple ways in which two electronic devices can become each other's trusted devices.

[0103] Optionally, two electronic devices can become each other's trusted devices after logging into the same identity account. The identity account can be a mobile phone number, an instant messaging application account, or a login account for any other type of application; the specific type and content of the identity account are not limited in this embodiment.

[0104] For example, let's take electronic device 100 and electronic device 200 as examples of each other being trusted devices. If electronic device 100 logs into instant messaging account 1 and passes the identity authentication (verification) during the login process, then electronic device 100 can be identified as a trusted device of instant messaging account 1. If electronic device 200 logs into instant messaging account 1 and passes the identity authentication (verification) during the login process, then electronic device 200 can also be identified as a trusted device of instant messaging account 1. In this case, electronic device 100 and electronic device 200 can be considered as trusted devices of each other.

[0105] Optionally, two electronic devices can become each other's trusted devices after authenticating each other's identities. This authentication can be authentication during WiFi connection, NFC connection, or Bluetooth connection (i.e., pairing). Understandably, after the two electronic devices authenticate each other, a trusted communication link (which can be simply referred to as a trusted link) can be established. A trusted link can be understood as an encrypted transmission link.

[0106] For example, after electronic device 100 and electronic device 300 have undergone the aforementioned Figure 2 After identity authentication during the Bluetooth pairing process, electronic device 100 and electronic device 300 become each other's trusted devices.

[0107] It should be noted that the trust relationship between electronic devices is transitive and is independent of how they become trusted devices. For example, if electronic device 100 and electronic device 300 are trusted devices because they are logged into the same account, and electronic device 200 and electronic device 300 are trusted devices because they have authenticated each other, then electronic device 100 and electronic device 200 are also trusted devices.

[0108] In this embodiment, trusted devices can share (or reuse, synchronize, or share) encryption keys. These encryption keys can be used by any two trusted devices to encrypt or decrypt transmitted data during data transmission. It should be noted that the content of the encryption key may differ depending on the specific application scenario.

[0109] In standard Bluetooth pairing scenarios, the encryption key can include keys for four security modes. A security mode refers to the security measures and protection levels employed by the Bluetooth device during connection establishment and data transmission. The security measures and protection levels used by the Bluetooth device differ across these four security modes, resulting in different data transmission security levels corresponding to the keys in each mode.

[0110] In this embodiment, the security modes may include: Security Mode 1, Security Mode 2, Security Mode 3, and Security Mode 4. Security Mode 1 is an insecure mode, Security Mode 2 is a service-level mandatory security mode, Security Mode 3 is a link-level mandatory security mode, and Security Mode 4 is a service-level mandatory security mode (with key pairing policy). The relationship between the data transmission security of the keys under these four security modes is: Security Mode 3 > Security Mode 4 > Security Mode 2 > Security Mode 1.

[0111] In this embodiment, keys with different data transmission security levels have different complexity. Specifically, keys with higher data transmission security can have higher complexity.

[0112] For example, if mobile phone 1 and mobile phone 2 use key 1 under security mode 3 to transmit data, mobile phone 1 and earphone use key 2 under security mode 4 to transmit data, and earphone and watch use key 3 under security mode 2 to transmit data, as described above, the data transmission security of the key under security mode 3 is higher than that of the key under security mode 4, and the data transmission security of the key under security mode 4 is higher than that of the key under security mode 2. Therefore, the complexity of key 1 is higher than that of key 2, and the complexity of key 2 is higher than that of key 3.

[0113] In one implementation, the complexity of the key can be related to its length. The longer the key, the higher its complexity. Thus, the longer the key, the more secure the data transmission.

[0114] For example, continuing with the above example, suppose the length of key 1 is a, the length of key 2 is b, and the length of key 3 is c. Then a is greater than b, and b is greater than c.

[0115] In another implementation, the complexity of the key can be related to the encryption algorithm used to generate it. The higher the complexity of the encryption algorithm, the higher the complexity of the key generated using that algorithm can be. Thus, for encryption keys requiring higher data transmission security, electronic devices can use more complex encryption algorithms to generate them.

[0116] For example, key 1 used between mobile phone 1 and mobile phone 2 is generated using an encryption algorithm with complexity d, key 2 used between mobile phone 1 and earphone is generated using an encryption algorithm with complexity e, and key 3 used between earphone and watch is generated using an encryption algorithm with complexity f. Then the complexity is: d is higher than e, and e is higher than f.

[0117] In this embodiment, the security modes supported by the Bluetooth device vary depending on the capabilities it supports (hereinafter referred to as device capabilities). Bluetooth devices with stronger capabilities offer higher data transmission security corresponding to keys in their supported security modes.

[0118] In one implementation, device capabilities can be related to the Bluetooth device's processing power, storage capacity, the age of the Bluetooth version, the age of the protocol version, hardware and software design, type, and cost.

[0119] Optionally, the stronger the processing power of a Bluetooth device, the more complex the security algorithms it can support, and thus the stronger its capabilities. The stronger the storage capacity of a Bluetooth device, the larger the length of keys it can store, and thus the stronger its capabilities. The more sophisticated the hardware and software design of a Bluetooth device, the stronger its capabilities. The newer the Bluetooth version or protocol version, the stronger its capabilities. Higher cost and better configuration of a Bluetooth device also contribute to its capabilities. Bluetooth devices classified as terminals can have stronger capabilities than those classified as peripherals.

[0120] In this embodiment, the security mode used between the two Bluetooth devices is associated with the security modes supported by both Bluetooth devices. For example, the security mode used between the two Bluetooth devices is a security mode supported by both Bluetooth devices. Another example is that the security mode used between the two Bluetooth devices is the security mode with the highest security level among the security modes supported by both Bluetooth devices.

[0121] For example, if the security modes supported by electronic device 100 include security mode 1, security mode 3 and security mode 4, and the security modes supported by electronic device 200 include security mode 2, security mode 3 and security mode 4, then the security modes adopted by electronic device 100 and electronic device 200 can be security mode 3 or security mode 4.

[0122] The type of security mode used for data transmission between different Bluetooth devices can also be related to the type of Bluetooth device. Different types of Bluetooth devices have different encryption security requirements when transmitting data, and therefore may use different security modes.

[0123] In this embodiment, the encryption security requirements for data transmission between terminals are higher than those for data transmission between terminals and peripherals, and the encryption security requirements for data transmission between terminals and peripherals are higher than those for data transmission between peripherals. Therefore, the security mode used for data transmission between terminals is more secure than the security mode used for data transmission between terminals and peripherals, and vice versa.

[0124] In this approach, the encryption security requirements for transmitting data with trusted devices can be determined based on the type of electronic device, and then the appropriate security mode can be determined based on those encryption security requirements.

[0125] In this embodiment of the application, under the above-described Bluetooth standard pairing scenario, the encryption key may not include the keys for the four security modes mentioned above. In this way, any two different Bluetooth devices can transmit data using the same encryption key.

[0126] If different Bluetooth devices use the same encryption key to transmit data, then the security of data transmission using the same encryption key is the same across different Bluetooth devices.

[0127] For example, if key "a" is used to transmit data between electronic devices 100 and 200, and between electronic devices 200 and 300, the security of data transmission between electronic devices 100 and 200 is the same as the security of data transmission between electronic devices 200 and 300.

[0128] In this embodiment of the application, in a BLE mesh scenario, the encryption key includes a network key, an application key, and a security function key. In this way, different Bluetooth devices can use the same encryption key to transmit data.

[0129] In this embodiment of the application, the encryption key can be generated in multiple ways.

[0130] In one implementation, the electronic device can generate an encryption key after logging into an identity account. In this case, the encryption key is associated with the identity account, and the electronic device can query the associated encryption key based on the identity account.

[0131] In some embodiments, after logging into an account, the electronic device can determine whether an encryption key associated with that account exists, and if no such key exists, generate an encryption key. This avoids the electronic device from generating keys repeatedly.

[0132] In this embodiment, the electronic device can first query whether an encryption key associated with the identity account is stored locally, and if no encryption key associated with the identity account is stored locally, it can query whether an encryption key associated with the identity account is stored on the cloud server. Understandably, if an encryption key associated with the identity account is stored locally, the electronic device does not need to query the cloud server again to see if an encryption key associated with the identity account is stored, nor does it need to generate an encryption key.

[0133] In one optional implementation, the electronic device can proactively query the cloud server to see if it stores an encryption key associated with the account. For example, after logging into the account, the electronic device can send an encryption key query request to the cloud server, which includes the account information. Upon receiving the query request, the cloud server can send a query result to the electronic device. This query result can indicate whether an encryption key associated with the account exists or not. If the query result indicates that no encryption key is associated with the account, the electronic device generates an encryption key; if the query result indicates that an encryption key is associated with the account, the query result also includes the encryption key associated with the account, and the electronic device can parse the encryption key from the query result.

[0134] In one optional implementation, the electronic device can passively determine whether the cloud server stores an encryption key associated with the identity account. For example, the electronic device can determine whether it has received an encryption key associated with the identity account within a first period of time after logging in. If the electronic device does not receive an encryption key associated with the identity account from the cloud server within the first period of time after logging in, it indicates that no encryption key associated with the identity account exists, and the electronic device can generate an encryption key. The specific value of the first period of time is not limited.

[0135] In one possible design, the electronic device can generate an encryption key based on its logged-in identity account, or it can generate an encryption key based on its logged-in identity account and device information. For example, the electronic device can generate an encryption key based on the identity account and a generated random number using a preset encryption algorithm, provided that no encryption key is associated with that identity account.

[0136] In another implementation, electronic devices can also generate encryption keys without logging into an account. In this case, the encryption key is associated with device information, and the electronic device can generate its associated encryption key based on that device information.

[0137] The device information may include the MAC address of the electronic device and / or the device identification code, etc., without specific restrictions.

[0138] In some embodiments, the electronic device may generate an encryption key based on device information during factory setup, when the device is activated, or during (or after) a device upgrade.

[0139] It should be noted that the above-described method for generating shared encryption keys is only an example and does not constitute a limitation on the embodiments of this application.

[0140] In this embodiment of the application, the electronic device can transmit data with its trusted device based on an encryption key. For example, the electronic device can use a target key from the encryption key to transmit data with its trusted device, wherein the target key is a key in a first security mode, and the first security mode is a security mode supported by both the electronic device and its trusted device.

[0141] For example, when two trusted electronic devices need to establish a connection, the security modes supported by both devices can be determined first, then the key corresponding to that security mode can be obtained, and data can be transmitted based on that key. When both electronic devices support multiple security modes, the appropriate security mode can be selected based on the encryption security requirements for data transmission between the devices; higher encryption security requirements allow for the selection of a more secure security mode.

[0142] Therefore, by determining the corresponding security mode based on the encryption security requirements of different electronic devices, determining the accurate key based on the security mode, and then using the key to perform targeted encryption transmission of data, the accuracy and intelligence of data transmission can be improved.

[0143] As can be seen from the above, an electronic device can share the acquired encryption key with at least one other electronic device that it trusts, so that the electronic device and its trusted device can directly transmit data based on the encryption key.

[0144] For example, the aforementioned electronic device 100 can share the acquired encryption key with electronic devices 200 and 300 that it trusts. In this way, any two of the electronic devices 100, 200 and 300 can transmit data directly based on the shared encryption key without Bluetooth pairing.

[0145] Therefore, any two trusted electronic devices can transmit data directly based on the acquired shared encryption key without Bluetooth pairing. On the one hand, this simplifies the data transmission process between Bluetooth devices; on the other hand, it ensures that data transmission between different electronic devices is secure and reliable.

[0146] The flow of the data transmission method provided in the embodiments of this application will be described below.

[0147] It should be noted that the electronic devices mentioned later (phone 1, phone 2, earphone 1, earphone 2) all have Bluetooth enabled, so they are not described again in the flowchart.

[0148] like Figure 6 The diagram shown is a flowchart of a data transmission method provided in an embodiment of this application. Wherein, Figure 6 Taking electronic device 100 as mobile phone 2, electronic device 200 as mobile phone 1, and electronic device 300 as earphone 1 as an example, the data transmission method provided in the embodiments of this application is illustrated by way of example. The data transmission method includes:

[0149] S601, Mobile Phone 2 obtains the encryption key.

[0150] In this embodiment, mobile phone 2 can actively generate encryption keys or obtain encryption keys from other trusted electronic devices.

[0151] Among these, mobile phone 2 can use multiple methods to actively generate encryption keys.

[0152] In one implementation, mobile phone 2 can generate an encryption key based on the logged-in identity account. In this method, the encryption key is associated with the identity account.

[0153] In another implementation, mobile phone 2 can generate an encryption key based on the logged-in account and device information. This device information can be the MAC address of mobile phone 2, and / or a device identification code, etc. In this method, the encryption key is associated with the account.

[0154] In another implementation, mobile phone 2 can generate an encryption key based on device information. In this method, the encryption key is associated with the device information.

[0155] It should be noted that whether or not the mobile phone 2 is logged into an identity account does not affect whether the encryption key is associated with the device information.

[0156] If mobile phone 2 is logged into an identity account, it can generate an encryption key if it is confirmed that no encryption key associated with the identity account exists. The implementation of how to confirm the existence of an encryption key associated with the identity account can be found in the aforementioned description and will not be repeated here.

[0157] If phone 2 is not logged into an account, an encryption key can be generated based on the device information during device upgrade. This can be done either when the device leaves the factory or when the device is activated.

[0158] Optionally, after logging into an identity account, mobile phone 2 can use a preset encryption algorithm to generate an encryption key based on the logged-in identity account and the generated random number.

[0159] Optionally, after logging into an identity account, mobile phone 2 can use a preset encryption algorithm to generate an encryption key based on the logged-in identity account, device information, and generated random numbers.

[0160] Optionally, the mobile phone 2 can generate an encryption key based on its MAC address and / or device identification code at the time of manufacture / device activation / upgrade.

[0161] In the passive acquisition method, mobile phone 2 can obtain the encryption key from other trusted electronic devices if it detects that the encryption key is not stored locally. The encryption key in this method can be associated with an identity account, an identity account and device information, or simply device information.

[0162] Alternatively, the phone can also obtain the encryption key from a cloud server.

[0163] In this embodiment, the encryption key obtained through the above generation method may include keys from the aforementioned four security modes, or keys with the same security level. For details, please refer to the foregoing descriptions; further elaboration will not be repeated here.

[0164] After obtaining the encryption key, mobile phone 2 can store the encryption key locally. It can also share the encryption key with trusted devices.

[0165] One implementation method is that mobile phone 2 can share the encryption key with a trusted device via cloud synchronization. Therefore, to facilitate the backup of the encryption key and to facilitate its subsequent sharing with trusted devices of mobile phone 2 via cloud synchronization, mobile phone 2 can send the encryption key to a cloud server for storage.

[0166] As another implementation, mobile phone 2 can share encryption keys with trusted devices via a trusted link, corresponding to S602 and S606. This trusted link can be an authenticated communication link such as WiFi, Bluetooth, or NFC.

[0167] S602, Mobile Phone 2 and Headphone 1 establish a trusted relationship.

[0168] In this embodiment, the encryption key generated by mobile phone 2 can be shared with a trusted device of mobile phone 2. However, if the object to which mobile phone 2 shares the encryption key (hereinafter referred to as the sharing object) is not a trusted device of mobile phone 2, a trusted relationship between mobile phone 2 and the sharing object needs to be established first.

[0169] For example, if the shared object of mobile phone 2 is earphone 1, and earphone 1 is not a trusted device of mobile phone 2, then mobile phone 2 needs to first establish a trusted relationship with earphone 1. There are several ways for mobile phone 2 to establish a trusted relationship with earphone 1; details are provided above and will not be repeated here.

[0170] S603, Mobile Phone 2 sends an encryption key to Headset 1.

[0171] Once a trusted relationship is established between mobile phone 2 and earphone 1, mobile phone 2 can send an encryption key to earphone 1. At this point, the process of mobile phone 2 sending the encryption key to earphone 1 is encrypted, therefore the process of sending the encryption key is secure.

[0172] In one implementation, the mobile phone 2 can first determine the security mode supported by the headset 1, and then send the key of that security mode to the headset 1.

[0173] In another implementation, before sending the encryption key to the headset 1, the mobile phone 2 can first determine the types of the mobile phone 2 and the headset 1, determine the encryption security requirements when transmitting data between the two, then determine the security mode corresponding to the encryption security requirements, and then send the key in the security mode to the headset 1.

[0174] In another implementation, mobile phone 2 does not need to first determine the security mode supported by headset 1, but can directly send the acquired encryption key to headset 1. In this method, mobile phone 2 sends the same encryption key to all trusted devices.

[0175] The method by which mobile phone 2 sends the encryption key to earphone 1 can be found in the previous section on how mobile phone 2 shares the encryption key with a trusted device, and will not be repeated here.

[0176] It should be noted that when phone 2 shares its encryption key with earphone 1, it means that phone 2 and earphone 1 have determined the key required for data transmission without Bluetooth pairing. However, data transmission is only possible when earphone 1 is within phone 2's Bluetooth communication range. Therefore, phone 2 needs to scan for available devices within its Bluetooth communication range. This can be done by sending a Bluetooth broadcast signal.

[0177] S604, Mobile Phone 2 scans Earphone 1.

[0178] In one implementation, if the mobile phone 2 scans the earphone 1, it means that the earphone 1 is within the Bluetooth communication range of the mobile phone 2. In this way, the mobile phone 2 can identify the earphone 1 as a device to be connected and transmit data with it.

[0179] It should be noted that if mobile phone 2 scans for only one available device, and that device is headset 1, then headset 1 can be directly identified as the device to be connected. If mobile phone 2 scans for multiple available devices, including headset 1, headset 1 can be identified as the device to be connected when it is closest to mobile phone 2; or mobile phone 2 can identify headset 1 as the device to be connected in response to the user's action of playing audio (or making a voice call); or it can identify headset 1 as the device to be connected in response to the user's selection action.

[0180] S605, mobile phone 2 and earphone 1 transmit data based on encryption keys.

[0181] After mobile phone 2 shares the encryption key with earphone 1, mobile phone 2 and earphone 1 determine the key required for data transmission without Bluetooth pairing. Thus, mobile phone 2 can transmit data with earphone 1 based on the encryption key after scanning earphone 1.

[0182] Among them, mobile phone 2 can first determine the security mode used (access) for communication between mobile phone 2 and headset 1, and then determine the key in the security mode as the key required for data transmission.

[0183] Alternatively, mobile phone 2 can directly determine the obtained encryption key as the key required for transmitting data.

[0184] Alternatively, mobile phone 2 can first determine the encryption security requirements when transmitting data with earphone 1, then determine the corresponding security mode based on the encryption security requirements, and then determine the key in the security mode as the key required for transmitting data.

[0185] It should be noted that mobile phone 2 and earphone 1 can also decrypt communication data based on the above encryption key.

[0186] The above steps S601 to S605 describe the process of mobile phone 2 obtaining the encryption key, establishing a trusted relationship between mobile phone 2 and earphone 1, sharing the key, and transmitting data. In reality, when a user owns a large number of electronic devices, other electronic devices may also become trusted devices for mobile phone 2. The following description uses mobile phone 1 as an example of another electronic device to illustrate the process of establishing a trusted relationship and transmitting data between mobile phone 2 and mobile phone 1.

[0187] S606, Mobile Phone 2 establishes a trusted relationship with Mobile Phone 1.

[0188] The method by which mobile phone 2 establishes a trusted relationship with mobile phone 1 can be referred to the above-described method for establishing a trusted relationship between mobile phone 2 and earphone 1, and will not be repeated here.

[0189] The difference is that mobile phone 1 can log in with an identity account, so mobile phone 2 and mobile phone 1 can also have a trusted relationship after logging in with the same identity account.

[0190] S607, Mobile Phone 2 sends an encryption key to Mobile Phone 1.

[0191] Similar to step S603, once a trusted relationship is established between mobile phone 2 and mobile phone 1, they are mutually trusted devices, and mobile phone 2 can share encryption keys with mobile phone 1. The data transmission process between mobile phone 2 and mobile phone 1 is encrypted, thus reducing the risk of data leakage.

[0192] The method of sharing the encryption key from mobile phone 2 to mobile phone 1 can be referred to the method of sharing the encryption key from mobile phone 2 to headset 1, and will not be repeated here.

[0193] It is worth noting that mobile phone 1 may support more security modes than headset 1. Therefore, the number of keys sent by mobile phone 2 to mobile phone 1 may be greater than the number of keys sent by mobile phone 2 to headset 1. For example, if the encryption key generated by mobile phone 2 includes keys under the above four security modes, mobile phone 2 can send keys under security level 1, security level 2, security level 3, and security level 4 to mobile phone 1, and mobile phone 2 can send keys under security level 1 and security level 2 to headset 1.

[0194] In this embodiment, when an encryption key is distributed to mobile phone 1, mobile phone 1 can transmit data with mobile phone 2 based on the distributed encryption key (refer to the data transmission process between mobile phone 2 and earphone 1, which is omitted in this embodiment). Mobile phone 1 can also transmit data with other trusted devices based on the distributed encryption key.

[0195] For example, in conjunction with the foregoing description, mobile phone 2 and earphone 1 are trusted devices to each other, and mobile phone 2 and mobile phone 1 are trusted devices to each other. Furthermore, the trust relationship between devices is transferable; therefore, mobile phone 1 and earphone 1 are also trusted devices to each other. In this manner, if earphone 1 is within the Bluetooth communication range of mobile phone 1, mobile phone 1 can transmit data with earphone 1 based on an encryption key, corresponding to step S609.

[0196] It should be noted that before transmitting data to the headset 1 based on the distributed encryption key, the mobile phone 1 needs to confirm whether the headset 1 is within its Bluetooth communication range. Therefore, the mobile phone 1 needs to scan for available devices within its Bluetooth communication range.

[0197] S608, Mobile Phone 1 scans Earphone 1.

[0198] In one implementation, if mobile phone 1 detects earphone 1, it means that earphone 1 is within the Bluetooth communication range of mobile phone 1. Thus, mobile phone 1 can identify earphone 1 as a device to be connected and transmit data with it. The process by which mobile phone 1 determines its connection with earphone 1 can be referred to the previous section on how mobile phone 2 determines its connection with earphone 1, and will not be repeated here.

[0199] S609, mobile phone 1 and earphone 1 transmit data based on encryption keys.

[0200] The process of transmitting data between mobile phone 1 and earphone 1 based on an encryption key can be referred to in the previous section on transmitting data between mobile phone 2 and earphone 1 based on an encryption key, and will not be repeated here.

[0201] Here, since mobile phone 2 shares the encryption key with earphone 1, with which it has a trusted relationship, and then encrypts the data during the data transmission process with earphone 1 using the shared encryption key, the data transmission process between mobile phone 2 and earphone 1 is secure and reliable.

[0202] Therefore, by establishing a trusted relationship between different devices, mutually trusted electronic devices can directly transmit data based on a shared encryption key without the need to generate a separate encryption key, simplifying the overall data transmission process between devices. Furthermore, by transmitting the trusted relationship between devices, data transmission between multiple devices becomes simpler, thereby simplifying the data transmission process between multiple devices and improving the user experience.

[0203] like Figure 7 The diagram shown is a flowchart of another data transmission method provided in an embodiment of this application. Wherein, Figure 7 Taking electronic device 100 as mobile phone 2, electronic device 200 as mobile phone 1, and electronic device 300 as earphone 1 as an example, the data transmission method provided in the embodiments of this application is illustrated by way of example. The data transmission method includes:

[0204] S701, Mobile Phone 2 Login Account 1.

[0205] Account 1 can be the aforementioned identity account.

[0206] In one implementation, mobile phone 2 can respond to a login operation applied to account 1 and log in to account 1.

[0207] In this embodiment of the application, if mobile phone 2 has logged into account 1 and passed the identity verification process of account 1, mobile phone 2 can be identified as a trusted device of account 1.

[0208] S702, Mobile Phone 2 determines whether there is an encryption key associated with Account 1.

[0209] If phone 2 is logged into account 1, to avoid repeatedly generating encryption keys associated with account 1, it can first check if an encryption key associated with account 1 already exists. The specific check process can be found in the previous text.

[0210] Specifically, if it is determined that an encryption key associated with account 1 exists, step S705 is executed; if it is determined that no encryption key associated with account 1 exists, step S703 is executed.

[0211] S703. Generate an encryption key, which is then associated with account 1.

[0212] The specific implementation of step S703 can be found in the description of step S601 in the aforementioned data transmission method, and will not be repeated here.

[0213] It is worth noting that when mobile phone 2 is logged into account 1, it can generate an encryption key based on account 1 or based on device information. If the encryption key is generated based on account 1, the generated encryption key is associated with account 1; if the encryption key is generated based on device information, the generated encryption key is associated with both account 1 and device information.

[0214] After generating the encryption key, mobile phone 2 can share the encryption key with a trusted device. In one way, mobile phone 2 can share the encryption key with a trusted device via cloud sharing (cloud synchronization), corresponding to step S704; in another way, mobile phone 2 can share the encryption key with a trusted device by establishing a trusted link, corresponding to steps S705-S707.

[0215] S704 and mobile phone 2 send key information to the cloud server. This key information carries an encryption key and account 1.

[0216] In order to facilitate the cloud server in recognizing the correspondence between the encryption key and account 1, mobile phone 2 can send encrypted information carrying the encryption key and account 1 to the cloud server.

[0217] By sending key information to the cloud server, mobile phone 2 can easily share encryption keys with its trusted devices via cloud synchronization.

[0218] S705, Mobile Phone 2 scans Earphone 1.

[0219] The specific implementation of step S705 can be referred to the relevant description of step S604 above, and will not be repeated here.

[0220] S706, mobile phone 2 and headset 1 establish Bluetooth connection.

[0221] In this embodiment, mobile phone 2 can synchronize the encryption key to headset 1 in various ways. This embodiment takes sending the encryption key from mobile phone 2 to mobile phone 1 via an encrypted link as an example.

[0222] The audio from mobile phone 2 can be output through headphones 1.

[0223] Mobile phone 2 can establish a Bluetooth connection with earphone 1 in various application scenarios to output audio through earphone 1.

[0224] In one implementation, mobile phone 2 can establish a Bluetooth connection with headset 1 in response to the opening operation of its audio / video playback application (audio playback application or video playback application).

[0225] As another implementation, the mobile phone 2 can establish a Bluetooth connection with the headset 1 when it detects that it is making or receiving a voice call.

[0226] As another implementation method, when the mobile phone 2 detects that its location is a public place (such as on the subway, in a hospital, school, classroom, office, etc.) and the mobile phone 2 is in audio playback or voice call mode, it can establish a Bluetooth connection with the headset 1.

[0227] After the mobile phone 2 establishes a Bluetooth connection with the earphone 1, the earphone 1 can be recognized by the mobile phone 2 as a trusted device. At this time, the mobile phone 2 can share the encryption key with the earphone 1, corresponding to step S806.

[0228] S707, Mobile Phone 2 sends an encryption key to Headset 1.

[0229] Once a Bluetooth connection is established between mobile phone 2 and earphone 1, mobile phone 2 can send an encryption key to earphone 1 through the transmission channel established by the Bluetooth connection. It is important to note that mobile phone 2 and earphone 1 can negotiate and obtain a key 'a' during the Bluetooth connection establishment process. Therefore, mobile phone 2 can use key 'a' to encrypt the encryption key, reducing the risk of the encryption key being leaked.

[0230] Other specific implementations of sending the encryption key from mobile phone 2 to earphone 1 can be found in the description of step S603 above, and will not be repeated here.

[0231] S708, mobile phone 2 sends a request to the cloud server to update the list of trusted devices, the request carrying the device identifier of earphone 1.

[0232] In this embodiment, after establishing a Bluetooth connection with the headset 1, the mobile phone 2 can add the headset 1 to its trusted device list to update its trusted device list.

[0233] In this method, mobile phone 2 can also send a request to the cloud server to update the list of trusted devices. In order to facilitate server identification, the request can carry the device identifier of earphone 1. In this way, the updated list of trusted devices of mobile phone 2 can be synchronized to the cloud server so that other trusted devices can obtain the latest list of trusted devices from the cloud server.

[0234] Understandably, when a user owns a large number of devices, there may be other devices that could also be trusted by Phone 2, for example... Figure 7 The mobile phone 1 shown can also become a trusted device of mobile phone 2. The process of mobile phone 1 becoming a trusted device of mobile phone 2 is described below in conjunction with step S709.

[0235] S709, Mobile Phone 1, Login Account 1.

[0236] In this embodiment, in response to the user's selection of mobile phone 2, mobile phone 1 establishes a trusted relationship with mobile phone 2. Mobile phone 1 and mobile phone 2 can establish a trusted relationship by logging into the same identity account. Specifically, mobile phone 1 can log into account 1 and pass the identity verification during the login process of account 1. At this time, mobile phone 1 can be identified as a trusted device of account 1. Since mobile phone 2 is also a trusted device of account 1, mobile phone 1 and mobile phone 2 can be trusted devices for each other.

[0237] For other specific implementations of logging into account 1 on mobile phone 1, please refer to the process of logging into account 1 on mobile phone 2, which will not be repeated here.

[0238] The S710 and cloud server send encryption keys and a list of trusted devices to mobile phone 1.

[0239] When mobile phone 1 is logged into account 1, it can obtain the encryption key sent by the cloud server, as well as a list of trusted devices that are mutually trusted by mobile phone 2. Mobile phone 1 can actively request the encryption key and trusted device list from the cloud server, or it can passively receive these information from the cloud server.

[0240] When mobile phone 1 and mobile phone 2 become trusted devices, mobile phone 1 can transmit data with mobile phone 2 (i.e., trusted device) and also transmit data with other untrusted devices within the Bluetooth communication range of mobile phone 1.

[0241] At this point, in order to more accurately determine which devices mobile phone 1 can transmit data with, mobile phone 1 can scan for available devices within its Bluetooth communication range, corresponding to step S711.

[0242] S711, Mobile Phone 1 scans Earphone 1.

[0243] In this embodiment, mobile phone 1 can scan for Bluetooth devices within its Bluetooth communication range to obtain a list of available devices. This list of available devices includes devices that can be from the aforementioned trusted device list (i.e., trusted devices of mobile phone 1), or devices that do not yet have a trusted relationship with mobile phone 1. In this embodiment, the example is taken where the trusted device list includes earphone 1, and earphone 1 is a trusted device of mobile phone 1.

[0244] In one optional implementation, after obtaining the list of available devices, mobile phone 1 can determine the data transmission object based on the detected operation request type. The determined data transmission object may differ depending on the type of the detected operation request.

[0245] For example, if the operation request currently detected by mobile phone 1 is an audio playback request, then mobile phone 1 can, in response to the audio playback request, identify headphones (e.g., headphones 1) as the device to be connected. If the operation request currently detected by mobile phone 1 is a data (file) transfer request, then mobile phone 1 can, in response to the data transfer request, identify mobile phone 2 as the device to be connected.

[0246] In another optional implementation, after obtaining the list of available devices, mobile phone 1 can further determine a trusted device from the list as the device to be connected. For example, mobile phone 1 can randomly determine a trusted device from the list of available devices. Also for example, each trusted device in the list of available devices displayed by mobile phone 1 has a trusted identifier, making it easier for the user to select a trusted device from the list as the device to be connected. Thus, mobile phone 1 can determine a trusted device (e.g., earphone 1) as the device to be connected in response to the user's selection of that trusted device. The selection operation can be a click operation or a long press operation, etc., and is not specifically limited.

[0247] Optionally, the user can select any device carrying the aforementioned trusted identifier from the available devices on mobile phone 1 as the device to be connected.

[0248] In this embodiment of the application, before the mobile phone 1 transmits data with the earphone 1, it needs to first establish a communication link for transmitting data, corresponding to step S712.

[0249] S712, Mobile Phone 1 and Headphone 1 establish ACL connection.

[0250] In this embodiment, as can be seen from the foregoing description, the trusted relationship between devices can be transmitted, because mobile phone 2 and earphone 1 are trusted devices to each other, and mobile phone 1 and mobile phone 2 are trusted devices to each other, so mobile phone 1 and earphone 1 are trusted devices to each other.

[0251] Furthermore, both mobile phone 1 and earphone 1 have obtained the encryption key. In this way, the encrypted connection between mobile phone 1 and earphone 1 only requires a data transmission link, so mobile phone 1 can directly establish an ACL connection with earphone 1.

[0252] S713, mobile phone 1 sends instruction 1 to headset 1, instruction 1 carries account 1 and security mode.

[0253] Understandably, the headset 1 may include keys for multiple different security modes. In order to specifically ensure the security of data transmission between the mobile phone 1 and the headset 1, the mobile phone 1 can send instruction 1 to the headset 1 to notify the headset 1 which security mode key to select for data transmission with the mobile phone 1.

[0254] Meanwhile, in order to help the headset 1 identify different encryption keys more clearly, the instruction 1 can carry account 1 to prompt the headset 1 to select the encryption key associated with account 1.

[0255] S714, Mobile Phone 1 determines the target key based on Account 1 and security mode.

[0256] Before transmitting data with earphone 1, mobile phone 1 first determines the encryption security requirements for data transmission between mobile phone 1 and earphone 1, then determines the security mode corresponding to the encryption security requirements, and finally determines the target key corresponding to the security mode from the encryption keys associated with account 1. In other words, the target key is associated with account 1 and the security mode used for data transmission between mobile phone 1 and earphone 1.

[0257] S715 and Headphone 1 determine the target key based on Account 1 and Security Mode.

[0258] Similarly, earphone 1 will also determine the target key following the above process. Furthermore, the target key determined by earphone 1 is the same as the target key determined by mobile phone 1.

[0259] It should be noted that in step S708 above, the trusted device list request sent by mobile phone 2 to the cloud server can also carry the security mode supported by headset 1. In this way, the instruction 1 sent by mobile phone 1 to headset 1 in step S713 may not include the security mode, and the implementation process of steps S714 and S715 remains unchanged, and will not be described again here.

[0260] S716, mobile phone 1 and earphone 1 transmit data based on target key.

[0261] In one approach, mobile phone 1 and earphone 1 can transmit data based on their respective determined target keys.

[0262] Thus, by transmitting trusted relationships between devices, different trusted electronic devices can share encryption keys without each device having to generate its own encryption key, thereby simplifying the data transmission process between different devices and improving data transmission efficiency.

[0263] like Figure 8 The diagram shown is a flowchart of another data transmission method provided in an embodiment of this application. Wherein, Figure 8 Taking electronic device 100 as mobile phone 2, electronic device 200 as mobile phone 1, electronic device 300 as earphone 1, and electronic device 500 as earphone 2 as examples, the data transmission method provided in the embodiments of this application is illustrated by way of example. The data transmission method includes:

[0264] S801, Mobile Phone 2 Login Account 1.

[0265] S802, Mobile Phone 2 determines whether there is an encryption key associated with Account 1.

[0266] S803 and mobile phone 2 generate an encryption key, which is then associated with account 1.

[0267] The specific implementation of steps S801 to S803 can be referred to the relevant descriptions of steps S701 to S703 in the aforementioned data transmission method, and will not be repeated here.

[0268] S804, mobile phone 2 and earphone 1 establish WiFi connection.

[0269] The specific implementation of establishing a WiFi connection between mobile phone 2 and earphone 1 can be found in the previous description, and will not be repeated here.

[0270] S805, mobile phone 2 sends encryption key to headset 1.

[0271] S806, mobile phone 2 and earphone 1 transmit data based on encryption keys.

[0272] In this embodiment, the specific implementation of steps S805 to S806 can be referred to the relevant description of S707 in the above data transmission method, and will not be repeated here.

[0273] S807, Mobile Phone 1 and Mobile Phone 2 establish a BT / WiFi connection.

[0274] In this embodiment, mobile phone 1 can establish a connection channel with mobile phone 2 via BT / WiFi communication in response to the user's selection of mobile phone 2. The specific establishment process can be found in the foregoing description and will not be repeated here.

[0275] S808, Mobile Phone 2 sends an encryption key and a list of trusted devices to Mobile Phone 1.

[0276] When mobile phone 1 and mobile phone 2 establish a BT / WiFi connection, mobile phone 1 is identified as a trusted device by mobile phone 2 (this can also be understood as mobile phone 1 and mobile phone 2 being mutually trusted devices). At this time, mobile phone 2 can share its encryption key and its list of trusted devices with mobile phone 1. Therefore, mobile phone 1 can receive the encryption key and the list of trusted devices sent by mobile phone 2. This list of trusted devices is a list of devices that are mutually trusted by mobile phone 2, and this list includes mobile phone 1.

[0277] and Figure 7 similar, Figure 8 When mobile phone 1 and mobile phone 2 become trusted devices, mobile phone 1 can transmit data with mobile phone 2 (i.e., trusted device) and can also transmit data with other untrusted devices within the Bluetooth communication range of mobile phone 1.

[0278] At this point, in order to more accurately determine which devices mobile phone 1 can transmit data with, mobile phone 1 can scan for available devices within its Bluetooth communication range, corresponding to step S809.

[0279] S809, Mobile Phone 1 scans to obtain a list of available devices, which includes Headphones 2.

[0280] The specific implementation of scanning the list of available devices by mobile phone 1 can be found in the description of step S711 above, and will not be repeated here.

[0281] It needs to be emphasized that, with Figure 7 The difference is, Figure 8 The list of available devices obtained by scanning with mobile phone 1 includes earphone 2, and earphone 2 has no trust relationship with mobile phone 2, mobile phone 1, or earphone 1.

[0282] In this method, if mobile phone 1 needs to transmit data with earphone 2, a trusted relationship needs to be established with earphone 2 first, corresponding to step S810.

[0283] S810, mobile phone 1 and earphone 2 establish a Bluetooth connection.

[0284] Since the earphone 2 and the mobile phone 1 do not yet have a trusted relationship, when the earphone 2 is identified as the device to be connected, the mobile phone 1 can first establish a trusted relationship with the earphone 2, and then share the encryption key with the earphone 2 on this basis.

[0285] As one implementation method, mobile phone 1 can establish a Bluetooth connection with earphone 2, making earphone 2 a trusted device of mobile phone 1. The specific process of establishing a Bluetooth connection can be found in the aforementioned descriptions and will not be repeated here.

[0286] S811, Mobile phone 1 sends an encryption key to headset 2.

[0287] After establishing a Bluetooth connection between mobile phone 1 and earphone 2, an encrypted connection channel exists between them. At this time, mobile phone 1 can send an encryption key to earphone 2 through this connection channel. The specific process of sending the encryption key can be referred to the relevant descriptions of steps S707 and S805 in the aforementioned data transmission method, and will not be repeated here.

[0288] Furthermore, mobile phone 1 and earphone 2 can transmit data based on this encryption key.

[0289] It should be noted that the above Figure 7 as well as Figure 8The earphones 1 and 2 mentioned are only examples of peripherals. In actual implementation, the earphones 1 and / or 2 can also be peripherals such as watches, bracelets, and Bluetooth speakers. There are no specific limitations, and they will not be listed one by one.

[0290] As a result, electronic devices can flexibly select the devices to connect to and flexibly share encryption keys with other trusted electronic devices, improving the flexibility of data transmission between mutually trusted devices.

[0291] Figure 7 as well as Figure 8 Both describe the data transmission process of the encrypted key generated by mobile phone 2 and associated with the identity account (or associated with the identity account and device information). Figure 7 and Figure 8 The difference is, Figure 9 In the second example, the encryption key is generated based on device information, and at this point, the encryption key is only associated with the device information. The following section, in conjunction with the appendix... Figure 9 The data transmission process is described for the case where the encryption key is generated by mobile phone 2 based on device information.

[0292] like Figure 9 The diagram shown is a flowchart of another data transmission method provided in an embodiment of this application. Wherein, Figure 9 Taking electronic device 100 as mobile phone 2, electronic device 200 as mobile phone 1, and electronic device 300 as earphone 1 as an example, the data transmission method provided in the embodiments of this application is illustrated by way of example. The data transmission method includes:

[0293] S901, Earphone 1 generates an encryption key, which is associated with the device information of Earphone 1.

[0294] In this embodiment, trusted devices can share encryption keys. These encryption keys can be used by trusted devices to encrypt and decrypt data, thereby achieving encrypted data transmission.

[0295] In this embodiment, the earphone 1 can generate an encryption key based on its device information, which may be the MAC address and / or device identification code of the earphone 1, etc., without specific limitations. In this method, the encryption key is associated with the device identifier of the earphone 1.

[0296] As one implementation method, the earphone 1 can generate an encryption key based on the device information during factory settings, when the device is activated, or when the device is upgraded (or after the upgrade). The specific timing for the earphone 1 to generate the encryption key can be set according to actual needs; this is just an example.

[0297] S902, Earphone 1 scans to Phone 2.

[0298] S903, Earphone 1 and Mobile Phone 2 establish a Bluetooth connection.

[0299] The specific implementation of step S903 can be referred to the description of step S706 in the aforementioned data transmission method, and will not be repeated here.

[0300] S904, Earphone 1 sends an encryption key to Mobile Phone 2.

[0301] Once a Bluetooth connection is established between mobile phone 2 and earphone 1, mobile phone 2 and earphone 1 are trusted devices for each other, and earphone 1 can share encryption keys with mobile phone 2.

[0302] In this way, the earphone 1 can send the encryption key to the mobile phone 2 through the transmission channel established by the Bluetooth connection, and the mobile phone 2 can receive the encryption key sent by the earphone 1.

[0303] When mobile phone 2 receives the encryption key shared by earphone 1, mobile phone 2 will store the encryption key locally. At the same time, in order to facilitate backup or indirect sharing of the encryption key with other trusted devices, mobile phone 2 can also store the encryption key to a cloud server, corresponding to steps S905 to S907.

[0304] S905, Mobile Phone 2, Login Account 1.

[0305] The specific implementation of step S905 can be referred to the description of step S701 in the aforementioned data transmission method, and will not be repeated here. It should be noted that there is no sequential relationship between step S905 and steps S901 to S904; the above steps are only used as an example.

[0306] S906, mobile phone 2 sends key information to the cloud server, which includes the encryption key and the device identifier of earphone 1.

[0307] The specific implementation of step S906 can be referred to the description of step S704 in the aforementioned data transmission method, and will not be repeated here. The difference is that the key information sent by mobile phone 2 to the cloud server here carries the encryption key and the device identifier of earphone 1.

[0308] S907, mobile phone 2 sends a request to the cloud server to update the list of trusted devices, the request carrying the device identifier of earphone 1.

[0309] The specific implementation of step S907 can be referred to the description of S708 in the aforementioned data transmission method, and will not be repeated here.

[0310] S908, Mobile Phone 1, Login Account 1.

[0311] S909, the cloud server sends the encryption key and a list of trusted devices to mobile phone 1.

[0312] S910 and mobile phone 1 scan to obtain a list of available devices, including earphone 1.

[0313] S911, Mobile Phone 1 and Headphone 1 establish ACL connection.

[0314] In this embodiment, the specific implementation of steps S908 to S911 can refer to the relevant description of steps S709 to S712 in the above data transmission method, and will not be repeated here.

[0315] S912, Mobile phone 1 sends instruction 1 to headset 1, instruction 1 carries the device identifier and security mode of headset 1.

[0316] In order to help the headset 1 identify different encryption keys more clearly, instruction 1 may carry the device identifier of the headset 1 to prompt the headset 1 to select the encryption key that carries the device identifier of the headset 1.

[0317] S913, Mobile phone 1 determines the target key based on the device identifier and security mode of headset 1.

[0318] S914, Earphone 1 determines the target key based on the device identifier and security mode of Earphone 1.

[0319] Similarly, Headphone 1 will also determine the target key according to the above process.

[0320] Steps S912 to S915 can be found in steps S713 to S716 above, and will not be repeated here.

[0321] S915, mobile phone 1 and earphone 1 transmit data based on target key.

[0322] In one approach, mobile phone 1 and earphone 1 can transmit data based on their respective determined target keys.

[0323] Thus, by transmitting trusted relationships between devices, different trusted electronic devices can share encryption keys without each device having to generate its own encryption key, thereby simplifying the data transmission process between different devices and improving data transmission efficiency.

[0324] Compared to associating encryption keys with identity accounts, generating encryption keys that are associated with device information simplifies the encryption key generation process, thereby further simplifying the data transmission process between different devices and improving data transmission efficiency.

[0325] In this embodiment of the application, any electronic device can generate an encryption key based on device information. For example, Figure 9 The encryption key is generated by the peripheral device (earphone 1) and... Figure 9 The difference is, Figure 10 The encryption key can be generated by the terminal.

[0326] like Figure 10 The diagram shown is a flowchart of another data transmission method provided in an embodiment of this application. Wherein, Figure 10 Taking electronic device 100 as mobile phone 2, electronic device 200 as mobile phone 1, and electronic device 300 as earphone 1 as an example, the data transmission method provided in the embodiments of this application is illustrated by way of example. The data transmission method includes:

[0327] S1001, Mobile Phone 2 generates an encryption key, and the encryption key is associated with the device information of Mobile Phone 2.

[0328] In this embodiment, the encryption key can be generated by mobile phone 2. The method and timing of mobile phone 2 generating the encryption key can be referred to the aforementioned relevant descriptions, and will not be repeated here.

[0329] The encryption key generated by mobile phone 2 carries the device identifier of mobile phone 2, and... Figure 9 The encryption key generated by the earphone 1 shown is different.

[0330] S1002, Mobile Phone 2 establishes a BT / WiFi connection with Mobile Phone 1.

[0331] If mobile phone 2 needs to transmit data with mobile phone 1 after generating an encryption key, mobile phone 2 can establish a connection channel with mobile phone 1 through BT / WiFi or other means.

[0332] Once mobile phone 2 establishes a connection channel with mobile phone 1, mobile phone 1 and mobile phone 2 become trusted devices for each other, and mobile phone 2 can then share encryption keys with mobile phone 1.

[0333] S1003, Mobile phone 2 sends an encryption key and a list of trusted devices to mobile phone 1.

[0334] In one way, to facilitate the connection between mobile phone 1 and mobile phone 2 (or other devices that are trusted by mobile phone 2), mobile phone 2 can send an encryption key and a list of trusted devices to mobile phone 1.

[0335] The list of trusted devices includes mobile phone 1.

[0336] S1004. Mobile phone 1 scans to obtain a list of available devices, including headset 1.

[0337] When mobile phone 1 receives the encryption key and list of trusted devices sent by mobile phone 2, mobile phone 1 can directly connect to mobile phone 2 based on the encryption key, or it can connect to other devices besides mobile phone 2.

[0338] To ensure that mobile phone 1 can flexibly select the device to be connected, mobile phone 1 can trigger the scanning of available devices within its Bluetooth communication range when it receives the encryption key and trusted device list sent by mobile phone 2. In this way, mobile phone 1 obtains a list of available devices, which can include trusted devices of mobile phone 1 (such as mobile phone 2) and other devices within its Bluetooth communication range (i.e., devices that are not yet trusted by mobile phone 1, such as headset 1).

[0339] In this way, mobile phone 1 can identify trusted devices as devices to be connected, or it can identify untrusted devices within its Bluetooth communication range as devices to be connected.

[0340] For example, mobile phone 1 can identify mobile phone 2 as the device to be connected, or it can identify earphone 1 as the device to be connected. Here, earphone 1 is within the Bluetooth communication range of mobile phone 1, and there is no trusted relationship between earphone 1 and mobile phone 1.

[0341] This embodiment is illustrated using the example of mobile phone 1 identifying earphone 1 as the device to be connected.

[0342] S1005. Mobile phone 1 and headset 1 establish a Bluetooth connection.

[0343] It should be noted that the earphone 1 and the mobile phone 2 in this embodiment do not have a reliable relationship.

[0344] In this manner, mobile phone 1 can respond to the user's selection and establish a Bluetooth connection with earphone 1 to build a trusted relationship. The specific implementation of the Bluetooth connection establishment between mobile phone 1 and earphone 1 can be found in the aforementioned description and will not be repeated here.

[0345] S1006, Mobile phone 1 sends an encryption key to headset 1.

[0346] After establishing a Bluetooth connection between mobile phone 1 and earphone 1, mobile phone 1 and earphone 1 become trusted devices to each other. At this point, mobile phone 1 can share its acquired encryption key with earphone 1. As one implementation method, mobile phone 1 can proactively send the encryption key to earphone 1.

[0347] Furthermore, mobile phone 1 and earphone 1 can transmit data based on an encryption key. It is worth noting that this encryption key is the key required for the encryption security needed for Bluetooth communication between mobile phone 1 and earphone 1.

[0348] Compared to synchronizing keys via cloud synchronization, this implementation method synchronizes encryption keys via near-field wireless communication, which simplifies the encryption key synchronization process and further improves the data transmission process between different electronic devices.

[0349] This application provides a data transmission method applied to a first electronic device. The data transmission method includes: the first electronic device acquiring an encryption key; scanning Bluetooth devices within a first range to obtain available devices, the available devices including a second electronic device, the second electronic device storing the encryption key, the second electronic device being in an unpaired state with the first electronic device, and the second electronic device having a trusted relationship with the first electronic device; encrypting communication data based on the encryption key, the communication data being data transmitted between the first electronic device and the second electronic device via Bluetooth communication.

[0350] In this manner, the first electronic device can be as described above. Figures 6-10 Mobile phone 2 or mobile phone 1.

[0351] Wherein, if the first electronic device is the aforementioned Figures 6-10 If the mobile phone is 2, then the second electronic device can be the aforementioned Figures 6-10 The earphone 1 or mobile phone 1 in the middle, optionally, the second electronic device can also be the aforementioned. Figure 8 The second pair of headphones.

[0352] If the first electronic device is the aforementioned Figures 6-10 If the mobile phone is 1, then the second electronic device can be the aforementioned Figures 6-10 Alternatively, the second electronic device may also be the aforementioned mobile phone 2 or earphone 1. Figure 8 The second pair of headphones.

[0353] In one approach, if the first electronic device passively acquires the encryption key during the process of acquiring the encryption key, the first electronic device can acquire the encryption key in response to establishing a trusted relationship with a third electronic device, which stores the encryption key.

[0354] In this manner, the first electronic device can be as described above. Figures 6-10 The first electronic device is either a mobile phone 1 or an earphone 1. Wherein, if the first electronic device is the aforementioned... Figures 6-10 If the mobile phone is 1, then the third electronic device can be the aforementioned Figures 6-10 Mobile phone 2 in the middle. If the first electronic device is the aforementioned Figures 6-10 If the earphone 1 is mentioned, then the third electronic device can be the aforementioned Figures 6-10 Mobile phone 2 in the middle. Optionally, the first electronic device may also be the aforementioned Figure 8 In the case of earphone 2, the third electronic device can be the aforementioned Figure 8 Mobile phone 1.

[0355] In one manner, the first electronic device may also send an encryption key and an identifier of the encryption key to the fourth electronic device in response to establishing a trusted relationship with the fourth electronic device.

[0356] In this manner, the first electronic device can be the aforementioned Figures 6-10 The fourth electronic device can be the aforementioned mobile phone 2. Figures 6-10 The mobile phone 1 or the earphone 1 in the middle.

[0357] As one approach, the triggering timing for the first electronic device to encrypt communication data based on the encryption key can be: encrypting the communication data based on the encryption key when the first distance is less than the second distance. Here, the first distance is the distance between the second electronic device and the first electronic device, and the second distance is the distance between the fifth electronic device and the first electronic device.

[0358] In this manner, the first electronic device can be the aforementioned Figures 6-10 The second electronic device can be the aforementioned mobile phone 2. Figures 6-10 The fifth electronic device can be the aforementioned earphone 1. Figures 6-10 Mobile phone 1.

[0359] In summary, when a user owns a large number of electronic devices and wants to transfer data between different devices, compared to the prior art which involves transferring data between different devices via Bluetooth, the data transmission method provided in this application only requires the two devices transmitting data to have a trusted relationship and the same encryption key, without requiring each device to perform a separate Bluetooth pairing action, making the overall data transmission process simpler.

[0360] This application also provides an electronic device, which may include a processor, a memory, a display screen, a microphone, and a camera. The memory, display screen, camera, and microphone are coupled to the processor. The memory stores computer program code, which includes computer instructions. When the processor executes the computer instructions, the electronic device can perform the various functions or steps performed by the electronic device in the above method embodiments. The structure of this electronic device can be referred to... Figure 5 The structure of the electronic device shown.

[0361] This application also provides a computer storage medium that includes computer instructions. When the computer instructions are executed on an electronic device, the electronic device performs the various functions or steps performed by the electronic device in the above method embodiments.

[0362] This application also provides a computer program product that, when run on a computer, causes the computer to perform the various functions or steps performed by the electronic device in the above method embodiments.

[0363] Through the above description of the embodiments, those skilled in the art will clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0364] In the several embodiments provided in this example, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0365] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0366] Furthermore, in each embodiment of this invention, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0367] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments. The aforementioned storage medium includes various media capable of storing program code, such as flash memory, portable hard disk, read-only memory, random access memory, magnetic disk, or optical disk.

[0368] The above description is merely a specific implementation of this embodiment, but the protection scope of this embodiment is not limited thereto. Any changes or substitutions within the technical scope disclosed in this embodiment should be covered within the protection scope of this embodiment. Therefore, the protection scope of this embodiment should be determined by the protection scope of the claims.

Claims

1. A data transmission method, characterized in that, Applied to a first electronic device, the method includes: Obtain the encryption key; Scan Bluetooth devices within a first range to obtain available devices. The available devices include a second electronic device, which stores the encryption key. The second electronic device is in an unpaired state with the first electronic device, and the second electronic device and the first electronic device have a trusted relationship. The communication data is encrypted based on the encryption key, and the communication data is the data transmitted between the first electronic device and the second electronic device via Bluetooth communication.

2. The method according to claim 1, characterized in that, The process of obtaining the encryption key includes: In response to establishing a trusted relationship with a third electronic device, an encryption key is obtained, wherein the encryption key is stored in the third electronic device.

3. The method according to claim 2, characterized in that, The response to establishing a trusted relationship with a third electronic device and obtaining the encryption key includes: In response to logging into the same identity account as the third electronic device, the encryption key sent by the cloud server is received.

4. The method according to claim 2, characterized in that, The response to establishing a trusted relationship with a third electronic device and obtaining the encryption key includes: In response to completing identity authentication with the third electronic device, the device receives the encryption key sent by the third electronic device.

5. The method according to any one of claims 1-4, characterized in that, The process of obtaining the encryption key includes: After logging into the identity account, an encryption key is generated, which is associated with the identity account.

6. The method according to claim 5, characterized in that, The generation of the encryption key includes: The encryption key is generated if no encryption key is associated with the identity account.

7. The method according to claim 6, characterized in that, Before generating the encryption key, the method further includes: Check whether the encryption key associated with the identity account is stored; In response to the failure to find the encryption key associated with the identity account, an encryption key query request is sent to the cloud server; Based on the query results returned by the cloud server, it was determined that there is no encryption key associated with the identity account.

8. The method according to claim 6, characterized in that, Before generating the encryption key, the method further includes: Check whether the encryption key associated with the identity account is stored; In response to the failure to find an encryption key associated with the identity account, determine whether an encryption key associated with the identity account has been received within a first time period after logging into the identity account; If no encryption key associated with the identity account is received within a first period of time after logging into the identity account, it is determined that no encryption key associated with the identity account exists.

9. The method according to any one of claims 5-8, characterized in that, The generation of the encryption key includes: The encryption key is generated using a preset encryption algorithm based on at least one of the identity account and the device information of the first electronic device.

10. The method according to any one of claims 1-4, characterized in that, The process of obtaining the encryption key includes: An encryption key is generated based on the device information of the first electronic device at a first moment. The encryption key is associated with the device information. The first moment can be when the first electronic device is factory set, when the first electronic device is activated, or when the first electronic device is upgraded.

11. The method according to any one of claims 1-10, characterized in that, The method further includes: In response to establishing a trusted relationship with a fourth electronic device, the encryption key and an identifier of the encryption key are sent to the fourth electronic device.

12. The method according to any one of claims 1-10, characterized in that, The method further includes: After logging in with the account, the encryption key and its identifier are sent to the cloud server.

13. The method according to any one of claims 1-12, characterized in that, Before encrypting the communication data based on the encryption key, the method further includes: The first interface is displayed, which includes the second electronic device and a trusted identifier of the second electronic device. The trusted identifier of the second electronic device is used to indicate that the second electronic device is a trusted device of the first electronic device. The encryption of communication data based on the encryption key includes: In response to the user's selection of the second electronic device, the communication data is encrypted based on the encryption key.

14. The method according to any one of claims 1-12, characterized in that, The available devices also include a fifth electronic device, wherein encrypting communication data based on the encryption key includes: When the first distance is less than the second distance, the communication data is encrypted based on the encryption key. The first distance is the distance between the second electronic device and the first electronic device, and the second distance is the distance between the fifth electronic device and the first electronic device.

15. The method according to any one of claims 1-14, characterized in that, Before encrypting the communication data based on the encryption key, the method further includes: Establish an asynchronous, connectionless connection with the second electronic device; Send a data transmission instruction to the second electronic device, the data transmission instruction carrying an identifier of the encryption key.

16. The method according to claim 15, characterized in that, The encryption key includes multiple keys, each with a different security mode. The data transmission instruction also carries a target security mode, which corresponds to the encryption security requirements of the first electronic device and the second electronic device when transmitting data. Before encrypting the communication data based on the encryption key, the method further includes: Determine the target security mode used when transmitting data with the second electronic device; The target key is determined based on the identifier and the target security mode; The encryption of communication data based on the encryption key includes: The target key is used to encrypt communication data.

17. The method according to claim 15, characterized in that, The encryption key includes various different types of keys, and the data transmission instruction also carries the key type. Before encrypting the communication data based on the encryption key, the method further includes: The target key is determined based on the identifier and key type; The encryption of communication data based on the encryption key includes: The target key is used to encrypt communication data.

18. The method according to claim 17, characterized in that, The various types of keys include keys for Bluetooth standard pairing scenarios and keys for BLE mesh networking scenarios.

19. The method according to any one of claims 15-18, characterized in that, The identifier is the identity account associated with the encryption key and / or the device information associated with the encryption key.

20. A data transmission method, characterized in that, Applied to a network system, the network system including a first electronic device, a second electronic device, and a third electronic device, the method includes: The first electronic device obtains the encryption key; The first electronic device establishes a trusted relationship with the second electronic device and sends the encryption key to the second electronic device; In response to detecting the second electronic device, the first electronic device transmits data with the second electronic device based on the encryption key; The first electronic device establishes a trusted relationship with the third electronic device and sends the encryption key to the third electronic device; In response to scanning the second electronic device, the third electronic device transmits data with the second electronic device based on the encryption key.

21. An electronic device, characterized in that, The electronic device includes: a memory and one or more processors; wherein the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code including computer instructions, and when the one or more processors execute the computer instructions, the electronic device performs the method of any one of claims 1-20.

22. A computer storage medium, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1-20.

23. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1-20.

Images