Device connection method, related device and communication system

Abstract

The invention provides a device connection method, a related device and a communication system. The method may be applied to a communication system including a first device and a second device. The first device and the second device may store the session key after negotiating the session key. Under the condition that the first equipment and the second equipment need to be connected and transmit data again, if the first equipment successfully decrypts the data encrypted by the second equipment by using the stored session key corresponding to the second equipment, and the second equipment successfully decrypts the data encrypted by the first equipment by using the stored session key corresponding to the first equipment; and the first equipment and the second equipment can directly use the session keys of the opposite ends stored by the first equipment and the second equipment to carry out data encryption transmission. The device connection speed can be improved, and the experience of sharing data among different devices by a user is improved.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to device connection methods, related devices and communication systems. Background Technology

[0002] In today's information-rich world, users have an increasing demand for information sharing. For example, one user may need to share data such as pictures, videos, and text files from their device with another. Improving device connection speed during data sharing is a pressing issue that needs to be addressed. Summary of the Invention

[0003] This application provides a device connection method, related apparatus, and communication system. A first device stores a session key corresponding to a second device. A second device stores a session key corresponding to the first device. The first and second devices can perform two-way authentication using their respective stored peer-to-peer session keys. Upon successful authentication, the first and second devices can perform encrypted data transmission using their respective stored peer-to-peer session keys. The first and second devices do not need to renegotiate the session key during subsequent connections. This can improve the speed of device connection.

[0004] In a first aspect, this application provides a device connection method. This method is applied to a communication system including a first device and a second device. The first device queries the memory of the first device for a session key corresponding to the second device; if a first session key corresponding to the second device is found, the first device uses the first session key to encrypt first authentication data, generating first encrypted data, and sends the first encrypted data to the second device; the second device queries the memory of the second device for a session key corresponding to the first device; if a second session key corresponding to the first device is found, the second device uses the second session key to decrypt the first encrypted data; if the decryption of the first encrypted data is successful, the second device uses the second session key to encrypt second authentication data, generating second encrypted data, and sends the second encrypted data to the first device; if the first device successfully decrypts the second encrypted data using the first session key, the first device and the second device establish a first session, which is used for data transmission between applications in the first device and applications in the second device.

[0005] The establishment of a first session between the first device and the second device may include establishing a data transmission channel for transmitting business data.

[0006] As can be seen, if both the first device and the second device store a session key that they have previously negotiated, they can use this session key to achieve encrypted data transmission without needing to renegotiate the session key. This can improve the speed of device connection and enhance the user's data sharing experience. Furthermore, the session key used to encrypt data during transmission is the same session key that the first and second devices have previously negotiated. Therefore, the above method can also ensure the security of data transmission between the first device and the second device.

[0007] In conjunction with the first aspect, in some embodiments, before the first device queries the session key corresponding to the second device in its memory, the first device receives an operation for sending first data to the second device. After the first device and the second device establish a first session, the first device encrypts the first data using the first session key to generate third encrypted data, and sends the third encrypted data to the second device.

[0008] The aforementioned first data may be business data, including but not limited to: text data, image data, audio streams, video streams, etc. The operations described above for sending the first data to the second device can be referenced in this application. Figure 6B The operation of device option 623 is shown.

[0009] As can be seen, when an operation to share data is received, the first device can connect to the second device. In scenarios where this is not the first connection, the first and second devices can use a previously negotiated session key to achieve encrypted data transmission without needing to renegotiate the session key. This improves the speed of device connections and enhances the user experience for data sharing.

[0010] In conjunction with the first aspect, in some embodiments, a first device is logged into a first device account, a second device is logged into a second device account, the first device includes a first application, the second device includes a second application, and a first session is used for data transmission between the first and second applications; the first device retrieves the first session key based on the device ID of the second device, the account ID of the second device account, the identifier of the first application, and the identifier of the second application. The second device retrieves the second session key based on the device ID of the first device, the account ID of the first device account, the identifier of the first application, and the identifier of the second application.

[0011] For example, the first device can be electronic device 201 in a later embodiment of this application. The second device can be electronic device 202 in a later embodiment of this application. The first application can refer to this application. Figure 8 The data sharing application shown is 1. For a second application, please refer to this community information. Figure 8 The data sharing application shown is 2.

[0012] Both the first and second devices can store a different account session key data table. The different account session key data table can be referred to as Table 1 in subsequent embodiments of this application.

[0013] As can be seen, when transmitting data between devices with different accounts, the electronic device can look up the session key based on the receiving device ID, the receiving account ID, the sending application identifier, and the receiving application identifier. Within devices with different accounts, the session keys used for data transmission between different groups of applications (e.g., between the first and second applications, or between the third and fourth applications) are different. Therefore, when the first application in the first device needs to transmit data again with the second application in the second device, both devices can look up the session key negotiated when they previously transmitted data. This improves data transmission security and prevents session keys from being misused.

[0014] In some embodiments, the first device includes a third application. The second device includes a fourth application. When the third application needs to transmit data with the fourth application, the first device can query the session key corresponding to the second device based on the device ID of the second device, the account ID of the second device account, the identifier of the third application, and the representation of the fourth application. The second device can query the session key corresponding to the first device based on the device ID of the first device, the account ID of the first device account, the identifier of the third application, and the representation of the fourth application.

[0015] In conjunction with the first aspect, in some embodiments, the first authentication data is determined based on the device ID of the first device and the account ID of the first device account, and the second authentication data is determined based on the device ID of the second device and the account ID of the second device account; or, the first authentication data includes a first random number, and the second authentication data includes data obtained by decrypting the first encrypted data using a second session key.

[0016] For example, the first device can hash and truncate its device ID and account ID. The first device can then use the hashed and truncated device ID and account ID to generate first authentication data. Alternatively, the first device can generate a first random number and use this random number as the first authentication data.

[0017] Alternatively, the second authentication data may include data obtained by decrypting the first encrypted data using the second session key and adding a preset value (e.g., adding 1 or 2, etc.).

[0018] In conjunction with the first aspect, in some embodiments, when the second device logs out of the second device account, the first device deletes the session key corresponding to the second device; the second device deletes the session key corresponding to the first device.

[0019] As can be seen, due to the change in the logged-in device account on the second device, the session key previously negotiated between the first and second devices, even if it hasn't expired, is no longer usable. Therefore, the first device can delete the session key associated with the second device and directly renegotiate the session key when connecting to the second device subsequently. This avoids having to renegotiate the session key again after failing to perform two-way authentication using the aforementioned expired but unusable session key when connecting to the second device in subsequent connections.

[0020] In conjunction with the first aspect, in some embodiments, a first device account is logged in on the first device, while no device account is logged in on the second device. The first device includes a first application, and the second device includes a second application. A first session is used for data transmission between the first application and the second application. The first device queries the first session key based on the device ID of the second device, the identifier of the first application, and the identifier of the second application. The second device queries the second session key based on the device ID of the first device, the account ID of the first device account, the identifier of the first application, and the identifier of the second application.

[0021] It can be seen that electronic devices logged into with a device account and those not logged into with a device account can be considered as devices with different accounts. When the second device is not logged into with a device account, the first device can retrieve the first key based on the second device's device ID, the identifier of the first application, and the identifier of the second application. If the receiving account ID associated with the first session key is empty, then the first session key is the session key corresponding to the second device. In this way, electronic devices logged into with a device account and those not logged into with a device account can quickly establish non-first-time connections based on previously negotiated session keys.

[0022] In conjunction with the first aspect, in some embodiments, if the first device fails to find the first session key, or the second device fails to find the second session key, or the second device fails to decrypt the first authentication data using the second session key, or the first device fails to decrypt the second authentication data using the first session key, then the first device and the second device use the first device authentication algorithm to perform device authentication and negotiate to obtain a third session key to establish a first session; wherein the first device and the second device store the third session key.

[0023] As can be seen, after negotiating a new session key, the first and second devices can store the session key so that it can be reused for encrypted data transmission when connecting again in the future, thereby improving the speed of device connection.

[0024] In conjunction with the first aspect, in some embodiments, the first device account is logged in on both the first device and the second device; before the first device queries the session key corresponding to the second device in the memory of the first device, the first device detects that the second device is offline, and the second device detects that the first device is online.

[0025] For example, the first device can be electronic device 201 in a later embodiment of this application. The second device can be electronic device 203 in a later embodiment of this application. That is, the first device and the second device are devices with the same account.

[0026] The first device may store a list of online devices. The first device can determine whether the second device is online by checking if the second device is in the first device's online device list. If the second device is not in the first device's online device list, the first device can confirm that the second device is offline. The second device may store a list of online devices. The second device can determine whether the first device is online by checking if the first device is in the second device's online device list. If the first device is in the second device's online device list, the second device can confirm that the first device is online.

[0027] Understandably, when the first device detects that the second device is online, and the second device detects that the first device is online, the first device and the second device can complete data transmission based on the soft bus.

[0028] As can be seen, when the first device needs to send data to the second device, and the first device detects that the second device is offline, the first device can confirm the second device's online status by successfully authenticating the second device using a historical session key. This allows both the first and second devices to skip the device authentication algorithm for device authentication before confirming the second device's online status, enabling rapid connection and improving the user experience of sharing data between devices with the same account. Furthermore, the session key used to encrypt data during transmission is a session key previously negotiated by the first and second devices and still valid. Therefore, the above method ensures the security of data transmission between the first and second devices.

[0029] In conjunction with the first aspect, in some embodiments, both the first device and the second device are logged into with the first device's account. Before the first device queries the second device's memory for the corresponding session key, the second device receives an operation to send second data to the first device, detects that the first device is online, and sends a message to the first device to establish a first session; the first device detects that the second device is offline. After the first device and the second device establish the first session, the second device uses the second session key to encrypt the second data, generates fourth encrypted data, and sends the fourth encrypted data to the first device.

[0030] As can be seen, when the second device needs to send data to the first device and detects that the first device is online, the second device can request to establish a first session with the first device. However, if the first device detects that the second device is offline, it can confirm the second device's online status by successfully authenticating it using a historical session key, thus establishing a first session. This allows both devices to skip the device authentication algorithm step of authenticating the second device before confirming its online status, enabling a faster connection and improving the user experience of sharing data between devices with the same account. Furthermore, the session key used to encrypt data during transmission is a session key previously negotiated by both devices and still valid. Therefore, this method ensures the security of data transmission between the first and second devices.

[0031] In conjunction with the first aspect, in some embodiments, both the first device and the second device are logged into with the first device's account. Before the first device queries the second device's memory for the corresponding session key, the second device receives an operation to send second data to the first device, detecting that the first device is online. Then, the second device can send a first broadcast to the first device. Upon receiving the first broadcast and finding the aforementioned first session key in its storage, the first device can confirm that the second device is online. Then, the first device and the second device can establish a first session and perform encrypted data transmission based on the first session key and the second session key.

[0032] As can be seen, if the first device can receive the first broadcast from the second device, even if the second device was previously offline to the first device, the first device can promptly update the second device's online status to online if it has the corresponding session key for the second device. This can significantly improve the speed of non-first-time connections between devices with the same account.

[0033] In conjunction with the first aspect, in some embodiments, when the first device account is logged in on both the first device and the second device, the first device queries the first session key based on the device ID of the second device; the second device queries the second session key based on the device ID of the first device.

[0034] It can be seen that in the same account session key data table, there is a one-to-one correspondence between the session key and the receiving device ID.

[0035] In conjunction with the first aspect, in some embodiments, if the first device fails to find the first session key, or the second device fails to find the second session key, or the second device fails to decrypt the first authentication data using the second session key, or the first device fails to decrypt the second authentication data using the first session key, then the first device and the second device use the first device authentication algorithm to perform device authentication and negotiate to obtain a fourth session key; the first device and the second device use the fourth session key and the second device authentication algorithm to perform device authentication and negotiate to obtain a fifth session key, and establish a first session; wherein the first device and the second device store the fifth session key.

[0036] For example, the first device authentication algorithm could be an authentication algorithm based on the Block Crypto Chain-Message Authenticity Check Code (CCMP) protocol. The second device authentication algorithm could be... Device authentication algorithms that enable secure interconnection between devices.

[0037] In conjunction with the first aspect, in some embodiments, when a timeout is detected in storing the first session key, the first device deletes the first session key; when a timeout is detected in storing the second session key, the second device deletes the second session key.

[0038] As can be seen, both the first and second devices can promptly delete session keys that have expired. This allows the first and second devices to periodically update the session keys, ensuring the security of data transmission based on these session keys.

[0039] Secondly, this application provides a device connection method. A first device queries a session key corresponding to a second device in its memory; if a first session key corresponding to the second device is found, the first device uses the first session key to encrypt first authentication data, generating first encrypted data, and sends the first encrypted data to the second device; the first device receives second encrypted data from the second device; if the first device successfully decrypts the second encrypted data using the first session key, the first device and the second device establish a first session, which is used for applications in the first device and applications in the second device to transmit data.

[0040] As can be seen, if both the first device and the second device store a session key that they have previously negotiated, they can use this session key to achieve encrypted data transmission without needing to renegotiate the session key. This can improve the speed of device connection and enhance the user's data sharing experience. Furthermore, the session key used to encrypt data during transmission is the same session key that the first and second devices have previously negotiated. Therefore, the above method can also ensure the security of data transmission between the first device and the second device.

[0041] In conjunction with the second aspect, in some embodiments, before the first device queries the memory of the second device for the session key corresponding to the second device, the first device receives an operation to send first data to the second device; after the first device and the second device establish a first session, the first device encrypts the first data using the first session key to generate third encrypted data, and sends the third encrypted data to the second device.

[0042] The aforementioned first data may be business data, including but not limited to: text data, image data, audio streams, video streams, etc. The operations described above for sending the first data to the second device can be referenced in this application. Figure 6B The operation of device option 623 is shown.

[0043] As can be seen, when an operation to share data is received, the first device can connect to the second device. In scenarios where this is not the first connection, the first and second devices can use a previously negotiated session key to achieve encrypted data transmission without needing to renegotiate the session key. This improves the speed of device connections and enhances the user experience for data sharing.

[0044] In conjunction with the second aspect, in some embodiments, a first device account is logged in on the first device, the first device includes a first application, and the first session is used for the first application and the second application on the second device to transmit data; the first device queries the first session key based on the device ID of the second device, the account ID of the second device account logged in on the second device, the identifier of the first application, and the identifier of the second application.

[0045] In conjunction with the second aspect, in some embodiments, the first authentication data is determined based on the device ID of the first device and the account ID of the first device account; or, the first authentication data includes a first random number.

[0046] In conjunction with the second aspect, in some embodiments, when it is detected that the device account logged in on the second device has switched from the second device account to the third device account, the first device deletes the session key corresponding to the second device.

[0047] As can be seen, due to the change in the logged-in device account on the second device, the session key previously negotiated between the first and second devices, even if it hasn't expired, is no longer usable. Therefore, the first device can delete the session key associated with the second device and directly renegotiate the session key when connecting to the second device subsequently. This avoids having to renegotiate the session key again after failing to perform two-way authentication using the aforementioned expired but unusable session key when connecting to the second device in subsequent connections.

[0048] In conjunction with the second aspect, in some embodiments, if the first device fails to find the first session key, or if the first device fails to decrypt the second authentication data using the first session key, the first device uses the first device authentication algorithm to authenticate the second device and negotiates with the second device to obtain a third session key, thereby establishing a first session; wherein the first device stores the third session key.

[0049] In conjunction with the second aspect, in some embodiments, a first device account is logged in on the first device. Before the first device queries the session key corresponding to the second device in the memory of the first device, the first device confirms that the account logged in on the second device is the first device account; the first device detects that the second device is offline.

[0050] As can be seen, when the first device needs to send data to the second device, and the first device detects that the second device is offline, the first device can confirm the second device's online status by successfully authenticating the second device using a historical session key. This allows both the first and second devices to skip the device authentication algorithm for device authentication before confirming the second device's online status, enabling rapid connection and improving the user experience of sharing data between devices with the same account. Furthermore, the session key used to encrypt data during transmission is a session key previously negotiated by the first and second devices and still valid. Therefore, the above method ensures the security of data transmission between the first and second devices.

[0051] In conjunction with the second aspect, in some embodiments, a first device account is logged in on the first device. Before the first device queries the session key corresponding to the second device in the memory of the first device, the first device receives a message from the second device for establishing a first session; the first device detects that the second device is offline; after the first device and the second device establish the first session, the first device receives fourth encrypted data from the second device and decrypts the fourth encrypted data using the first session key.

[0052] As can be seen, when the second device needs to send data to the first device and detects that the first device is online, the second device can request to establish a first session with the first device. However, if the first device detects that the second device is offline, it can confirm the second device's online status by successfully authenticating it using a historical session key, thus establishing a first session. This allows both devices to skip the device authentication algorithm step of authenticating the second device before confirming its online status, enabling a faster connection and improving the user experience of sharing data between devices with the same account. Furthermore, the session key used to encrypt data during transmission is a session key previously negotiated by both devices and still valid. Therefore, this method ensures the security of data transmission between the first and second devices.

[0053] In conjunction with the second aspect, in some embodiments, when the first device account is logged in on both the first device and the second device, the first device queries the first session key based on the device ID of the second device.

[0054] In conjunction with the second aspect, in some embodiments, when a timeout is detected in storing the first session key, the first device deletes the first session key.

[0055] As can be seen, the first device can promptly delete session keys that have expired. In this way, both the first and second devices can periodically update the session keys, ensuring the security of data transmission based on the session keys.

[0056] Thirdly, this application provides a device connection method. A second device receives first encrypted data from a first device; the second device queries the memory of the second device for a session key corresponding to the first device; if a second session key corresponding to the first device is found, the second device uses the second session key to decrypt the first encrypted data; if the first encrypted data is successfully decrypted, the second device uses the second session key to encrypt second authentication data, generating second encrypted data, and sends the second encrypted data to the first device; the second device and the first device establish a first session, which is used for applications in the first device and applications in the second device to transmit data.

[0057] As can be seen, if both the first device and the second device store a session key that they have previously negotiated, they can use this session key to achieve encrypted data transmission without needing to renegotiate the session key. This can improve the speed of device connection and enhance the user's data sharing experience. Furthermore, the session key used to encrypt data during transmission is the same session key that the first and second devices have previously negotiated. Therefore, the above method can also ensure the security of data transmission between the first device and the second device.

[0058] In conjunction with the third aspect, in some embodiments, the second device may or may not have a second device account logged in. The second device includes a second application, and the first session is used for data transmission between the second application and the first application in the first device. The second device queries the second session key based on the device ID of the first device, the account ID of the first device account logged in on the first device, the identifier of the first application, and the identifier of the second application.

[0059] In conjunction with the third aspect, in some embodiments, the second authentication data is determined based on the device ID of the second device and the account ID of the second device account; or, the second authentication data is determined based on the device ID of the second device; or, the second authentication data includes data obtained by decrypting the first encrypted data using the second session key.

[0060] In conjunction with the third aspect, in some embodiments, the device account logged in on the second device is switched from the second device account to the third device account; the second device deletes the session key corresponding to the first device.

[0061] As can be seen, due to the change in the device account logged in on the second device, the session key previously negotiated between the first and second devices, even if it has not yet expired, is no longer usable. Therefore, the second device can delete the session key associated with the first device and directly renegotiate the session key when connecting with the first device subsequently. This avoids the need to renegotiate the session key again after failing to perform two-way authentication using the aforementioned session key that has not yet expired but is actually unusable when connecting with the first device subsequently.

[0062] In conjunction with the third aspect, in some embodiments, if the second device fails to find the second session key, or if the second device fails to decrypt the first authentication data using the second session key, the second device uses the first device authentication algorithm to authenticate the first device and negotiates with the first device to obtain a third session key, thereby establishing a first session; wherein the second device stores the third session key.

[0063] In conjunction with the third aspect, in some embodiments, after the second device and the first device establish a first session, the second device receives third encrypted data from the first device and decrypts the third encrypted data using the second session key.

[0064] In conjunction with the third aspect, in some embodiments, the second device is logged into the account of the first device. Before the second device receives the first encrypted data from the first device, the second device receives an operation to send the second data to the first device, detects that the first device is online, and sends a message to the first device to establish a first session. After the second device and the first device establish the first session, the second device uses the second session key to encrypt the second data, generates the fourth encrypted data, and sends the fourth encrypted data to the first device.

[0065] As can be seen, when the second device needs to send data to the first device and detects that the first device is online, the second device can request to establish a first session with the first device. However, if the first device detects that the second device is offline, it can confirm the second device's online status by successfully authenticating it using a historical session key, thus establishing a first session. This allows both devices to skip the device authentication algorithm step of authenticating the second device before confirming its online status, enabling a faster connection and improving the user experience of sharing data between devices with the same account. Furthermore, the session key used to encrypt data during transmission is a session key previously negotiated by both devices and still valid. Therefore, this method ensures the security of data transmission between the first and second devices.

[0066] In conjunction with the third aspect, in some embodiments, when the first device account is logged in on both the first device and the second device, the second device queries the second session key based on the device ID of the first device.

[0067] In conjunction with the third aspect, in some embodiments, when a timeout is detected in storing the second session key, the second device deletes the second session key.

[0068] As can be seen, the second device can promptly delete session keys that have expired. In this way, both the first and second devices can periodically update the session keys, ensuring the security of data transmission based on the session keys.

[0069] Fourthly, this application provides an electronic device. The electronic device may include a memory and a processor. The memory may be used to store a computer program. The processor may be used to invoke the computer program to execute any possible implementation method as described in the second or third aspect.

[0070] Fifthly, this application provides a computer-readable storage medium storing instructions that, when executed by a processor, can implement any possible implementation method as described in the second or third aspect.

[0071] In a sixth aspect, this application provides a computer program product that may contain computer instructions that, when executed on a processor, can implement any of the possible implementation methods in the second or third aspect.

[0072] In a seventh aspect, this application provides a chip for use in an electronic device, the chip including one or more processors, the processors being configured to invoke computer instructions to cause the electronic device to perform any possible implementation method as described in the second or third aspect.

[0073] It is understood that the electronic device provided in the fourth aspect, the computer-readable storage medium provided in the fifth aspect, the computer program product provided in the sixth aspect, and the chip provided in the seventh aspect are all used to execute the methods provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here. Attached Figure Description

[0074] Figure 1 This is a schematic diagram of the architecture of a communication system provided in an embodiment of this application;

[0075] Figure 2 This is a schematic diagram of the architecture of another communication system provided in an embodiment of this application;

[0076] Figure 3 This is a schematic diagram of the hardware structure of the electronic device 100 provided in the embodiments of this application;

[0077] Figure 4 This is a schematic diagram of the software structure of the electronic device 100 provided in the embodiments of this application;

[0078] Figure 5 This is a schematic diagram of the software structure of another electronic device 100 provided in an embodiment of this application;

[0079] Figures 6A to 6C These are schematic diagrams illustrating some data sharing scenarios provided in the embodiments of this application;

[0080] Figure 7A This is a flowchart illustrating a method for connecting devices with different account numbers, as provided in an embodiment of this application.

[0081] Figure 7B This is a flowchart illustrating a method for negotiating session keys between devices with different account numbers, as provided in an embodiment of this application.

[0082] Figure 8 This is a flowchart of another method for connecting devices with different account numbers provided in an embodiment of this application;

[0083] Figure 9 This is a flowchart illustrating a method for connecting devices with the same account, as provided in an embodiment of this application.

[0084] Figure 10 This is a flowchart of another method for connecting devices with the same account, provided in an embodiment of this application.

[0085] Figure 11 This is a flowchart of another method for connecting devices with the same account, provided in an embodiment of this application. Detailed Implementation

[0086] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to limit the application. As used in the specification and appended claims of this application, the singular expressions "a," "the," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, "at least one" and "one or more" refer to one or more (including two). 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 alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0087] References to "one embodiment" or "some embodiments" in this specification 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 this specification 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 direct connections and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0088] 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.

[0089] To facilitate understanding of the device connection method provided in this application, some concepts involved in this application are introduced here.

[0090] 1. Devices with the same account and devices with different accounts.

[0091] Electronic devices can be logged into with a device account. For example, a device account could be... Account. This application embodiment does not limit the type of device account.

[0092] Devices with the same account can refer to multiple electronic devices logged into the same device account. For example, a user may own multiple electronic devices, including but not limited to: mobile phones, tablets, laptops, etc. A user can log into the same device account on all of their mobile phones, tablets, laptops, etc. In this case, the mobile phones, tablets, laptops, etc., logged into the same device account by that user are considered devices with the same account.

[0093] In some embodiments, some electronic devices do not have device account login functionality, but can be bound to electronic devices that are logged in with a device account. For example, headphones, smart bracelets, and other electronic devices may not have account login functionality. However, headphones and smart bracelets can be bound to a mobile phone. The aforementioned electronic devices that are not logged in with a device account and the electronic devices they are bound to can also be devices with the same account.

[0094] Devices with different accounts can refer to multiple electronic devices logged into different device accounts. For example, the device account logged into by User 1 on their electronic device is different from the device account logged into by User 2 on their electronic device. That is, the electronic device owned by User 1 and the electronic device owned by User 2 are devices with different accounts.

[0095] Furthermore, electronic devices logged into with a device account and those not logged into with a device account are considered to be devices with different accounts. Two electronic devices neither of which is logged into with a device account are also considered to be devices with different accounts.

[0096] 2. Softbus.

[0097] A software bus refers to a set of virtual data transmission lines that serve multiple components of various types written in multiple computer languages. These virtual data transmission lines are software; they are the interface for a set of common standard components, and a set of standard software modules. The software bus also serves as a virtual common channel and interface for data transmission and communication between the computer operating system and various components, or between components themselves.

[0098] A soft bus can serve as a communication base for distributed devices, providing a unified distributed communication capability for interconnection between devices. It enables rapid device discovery, connection, and efficient data transmission. Soft buses can also be referred to as distributed soft buses, among other names.

[0099] For example, a soft bus establishes an "invisible" bus between 1+8+N devices (1 represents mobile phones; 8 represents in-vehicle systems, speakers, headphones, watches, wristbands, tablets, large screens, personal computers (PCs), augmented reality (AR), and virtual reality (VR); N refers to other Internet of Things (IoT) devices). It features automatic discovery, instant connectivity, self-organizing networks (heterogeneous network networking), high bandwidth, low latency, and high reliability. In other words, based on the soft bus, devices can not only share data but also instantly interconnect with other devices on the same local area network or connected via Bluetooth. Furthermore, the soft bus can also share files between heterogeneous networks such as Bluetooth and Wireless-Fidelity (Wi-Fi) (for example, receiving files via Bluetooth on one hand and transferring files via Wi-Fi on the other).

[0100] In some embodiments, devices with the same account can transmit data via a soft bus.

[0101] 3. The equipment is online.

[0102] Devices with the same account can self-discover and self-network based on the soft bus. That is, an electronic device can discover other electronic devices with the same logged-in device account using the soft bus's device discovery technology. Furthermore, an electronic device can use the soft bus's device networking technology to authenticate the discovered devices with the same account and add the authenticated devices to its own device group, thus achieving device networking.

[0103] Electronic devices can determine whether the other device is online based on the device authentication results for devices under the same account. For example, electronic device 1 authenticates electronic device 2. If the authentication of electronic device 2 is successful, electronic device 1 determines that electronic device 2 is online (i.e., electronic device 2 is online from the perspective of electronic device 1); otherwise, electronic device 1 determines that electronic device 2 is offline (i.e., electronic device 2 is offline from the perspective of electronic device 1). As another example, electronic device 2 authenticates electronic device 1. If the authentication of electronic device 1 is successful, electronic device 2 determines that electronic device 1 is online (i.e., electronic device 1 is online from the perspective of electronic device 2); otherwise, electronic device 2 determines that electronic device 1 is offline (i.e., electronic device 1 is offline from the perspective of electronic device 2).

[0104] Electronic device 1 can authenticate one or more electronic devices it discovers and add the authenticated electronic devices to its stored online device list. That is, all electronic devices in the online device list stored by electronic device 1 are online devices as determined by electronic device 1. Electronic device 1 can detect whether other electronic devices are online based on its stored online device list. If device authentication fails again for an electronic device in the online list, electronic device 1 can remove that electronic device from the online list.

[0105] In some embodiments, devices with the same account can perform device authentication by calling the corresponding device authentication module via a software bus. This application does not limit the methods used for device authentication described above.

[0106] After multiple devices under the same account have successfully authenticated each other (i.e., mutually confirmed that the other end is online), these multiple devices under the same account can complete data transmission through the soft bus.

[0107] 4. Session.

[0108] A session can refer to the process of an application in one electronic device transmitting business data to an application in another electronic device. Business data is distinct from device connection data. Device connection data can include data used to establish communication connections between devices. Business data can include data generated by applications while providing services or functions, including but not limited to: audio data, video data, text data, etc. Scenarios for business data transmission can include, but are not limited to: file sharing scenarios, screen mirroring scenarios, multi-screen collaboration scenarios, etc. For example, application 1 in electronic device 1 needs to transmit business data to application 2 in electronic device 2. Application 1 and application 2 can negotiate a session key and establish a session. This session key can be used to encrypt the business data to be transmitted between application 1 and application 2 to ensure the security of business data transmission.

[0109] A session is related to the number of times business data is transmitted. For example, the session corresponding to application 1 in electronic device 1 sharing image 1 with application 2 in electronic device 2 in response to a user action is different from the session corresponding to application 1 in electronic device 1 sharing image 2 with application 2 in electronic device 2 in response to a user action. That is, when business data is transmitted multiple times from the same data sender to the same data receiver, the data sender and data receiver can create multiple sessions. One session can be considered as one business data transmission process between the data sender and data receiver.

[0110] Sessions are also related to the data sender and receiver. For example, the session corresponding to application 1 in electronic device 1 sharing image 1 with application 2 in electronic device 2 in response to a user action is different from the session corresponding to application 1 in electronic device 1 sharing image 3 with application 3 in electronic device 3 in response to a user action. That is, when the data sender used to transmit business data is different, and / or the data receiver is different, the session corresponding to business data transmission is different.

[0111] This application provides a device connection method. When transmitting business data between devices with different accounts, the data sending end can look up the session key corresponding to the data receiving end in its memory, and the data receiving end can also look up the session key corresponding to the data sending end in its memory. The data sending end and the data receiving end can perform two-way authentication based on the session keys corresponding to the peers stored in their respective memories.

[0112] If verification fails, or if at least one of the data sender and receiver does not store the corresponding session key for the other end, the data sender and receiver can perform device authentication and negotiate a new session key. The data sender can use the negotiated session key to encrypt the data to be transmitted and send it to the data receiver. Furthermore, both the data sender and receiver can store the negotiated session key for reuse in subsequent data transmissions.

[0113] If the verification is successful, the data sender can use its stored session key corresponding to the data receiver to encrypt the data to be transmitted and send it to the data receiver. In this way, the data sender and data receiver do not need to renegotiate the session key, which improves the speed of device connection and thus the speed of data transmission between devices.

[0114] Compared to existing technologies where session keys negotiated between electronic devices are only used for a single session and are not stored between devices, requiring re-authentication and negotiation of a new session key each time data is transmitted, this method addresses the issue of time-consuming communication connections and extended user waiting times for data sharing. The device connection method provided in this application stores negotiated session keys and sets their validity period. In cases where two electronic devices are connecting for the first time, they can use the still-valid session key of the peer device to complete two-way authentication and directly transmit data based on the valid session key, eliminating the need for renegotiation. This improves the speed of subsequent connections and enhances the user experience for data sharing.

[0115] When transmitting business data between devices with the same account, if both the data sender and receiver detect that the data receiver is online, they can directly use the soft bus to complete the data transmission. If either the data sender or receiver detects that the data receiver is offline, the soft bus of the data sender can look up the corresponding session key for the data receiver in its memory, and the soft bus of the data receiver can also look up the corresponding session key for the data sender in its memory. The soft buses of the data sender and receiver can perform two-way authentication based on their respective stored session keys.

[0116] If verification fails, or if at least one of the data sender and receiver does not store the corresponding session key, the data sender and receiver will re-authenticate their devices. After the data sender successfully authenticates the data receiver (i.e., the data receiver is online), and the data receiver successfully authenticates the data sender (i.e., the data sender is online), the data sender and receiver can negotiate a session key and implement encrypted data transmission based on the soft bus and the session key. After negotiating the session key, both the data sender and receiver can store it for reuse in subsequent data transmissions.

[0117] If verification is successful, the device online process is skipped, and the soft bus of the data sender and receiver can use their respective stored session keys to complete data transmission. This allows either the sender or receiver to skip the device online process and quickly establish a network if either detects the receiver is offline. This improves the connection speed between devices with the same account, thereby increasing the data transmission speed between them.

[0118] Figure 1 An exemplary schematic diagram of the architecture of a communication system provided in this application is shown.

[0119] like Figure 1 As shown, the communication system 10 may include smart glasses 101, mobile phone 102, earphones 103, tablet computer 104, router 105, speaker 106, and television 107.

[0120] Smart glasses 101, mobile phone 102, earphones 103, tablet computer 104, speaker 106, and TV 107 can be devices with the same account or devices with different accounts.

[0121] Smart glasses 101, mobile phone 102, earphones 103, tablet computer 104, speaker 106, and television 107 can be interconnected and transmit data. For example, mobile phone 102 can connect to tablet computer 104. Mobile phone 102 can send pictures, videos, text files, and other data from mobile phone 102 to tablet computer. Tablet computer 104 can also send data to mobile phone 102. Mobile phone can connect to television 107 and send videos to be played to television 107. Both mobile phone 102 and tablet computer 104 can connect to speaker 106. Mobile phone 102 or tablet computer 104 can send audio to be played to speaker 106. This application embodiment does not limit the method of connecting electronic devices in communication system 10. For example, the device connection method may include, but is not limited to: Bluetooth, Wi-Fi, near-field communication (NFC), ZigBee communication technology, ultra-wideband (UWB), etc.

[0122] Router 105 can be used to provide network access. Electronic devices accessing the network through router 105 can be within the same local area network.

[0123] In some embodiments, the electronic devices in the communication system 10 can be devices with the same account. After these devices are networked based on a soft bus, they can achieve data sharing and provide users with device collaboration functions (such as multi-screen collaboration, cross-device service calls, etc.).

[0124] Not limited to Figure 1 The communication system 10 may include more or fewer electronic devices, as shown in the diagram.

[0125] Figure 2 An exemplary schematic diagram of another communication system provided in this application is shown.

[0126] like Figure 2As shown, the communication system 20 may include electronic devices 201, 202, and 203. The device types of electronic devices 201 to 203 may be the same or different. This application embodiment does not limit the device types of electronic devices 201 to 203. For example, the device types of electronic devices 201 to 203 may include: mobile phones, tablet computers, laptops, in-vehicle systems, televisions, etc.

[0127] like Figure 2 As shown, the device account logged in on electronic devices 201 and 203 is device account 1. The device account logged in on electronic device 202 is device account 2. That is to say, electronic devices 201 and 203 are devices with the same account. Electronic devices 201 and 203 are devices with different accounts. Electronic devices 202 and 203 are also devices with different accounts.

[0128] Electronic devices 201 to 203 can be interconnected. For example, electronic device 201 can share data with both electronic device 202 and electronic device 203.

[0129] In some embodiments, before electronic devices 201 and 202 transmit data, they can perform device authentication on each other, and establish a data transmission channel after successful authentication, thereby using this data transmission channel to encrypt and transmit business data. The scenario of data transmission between electronic devices 201 and 202 can be referred to as a cross-account data transmission scenario.

[0130] Before data transmission occurs between electronic devices 201 and 203, they can discover, connect, and network each other via a soft bus. Then, they can transmit data through the soft bus. This scenario of data transmission between electronic devices 201 and 203 can be termed a same-account data transmission scenario.

[0131] In some embodiments, the method of device authentication between devices with different accounts can differ from the method of device authentication between devices with the same account. For example, electronic devices 201 and 202 can authenticate each other based on the counter code and CBC-MAC protocol (CCMP) authentication algorithm. The soft bus in electronic device 201 and the soft bus in electronic device 202 can call the device authentication module for device authentication, and the device authentication method can include... Device authentication algorithms (such as the Hichain authentication algorithm) are used to achieve secure device interconnection. This application does not limit the methods for device authentication between devices with different accounts or between devices with the same account.

[0132] The structure of the electronic device involved in this application is described below.

[0133] Figure 3 An exemplary schematic diagram of the hardware structure of electronic device 100 is shown.

[0134] Electronic device 100 can be Figure 1 Any electronic device in the communication system 10 shown can also be Figure 2 Any electronic device in the communication system 20 shown.

[0135] like Figure 3 As shown, the electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, a sensor module 180, buttons 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0136] It is understood that the structures illustrated in the embodiments of this application do not constitute a specific limitation on the electronic device 100. In other embodiments of this application, the electronic device 100 may include more or fewer components than illustrated, or combine some components, or split some components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0137] Processor 110 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), etc. Different processing units may be independent devices or integrated into one or more processors.

[0138] The controller can be the nerve center and command center of the electronic device 100. The controller can generate operation control signals according to the instruction opcode and timing signals to complete the control of fetching and executing instructions.

[0139] The processor 110 may also include a memory for storing instructions and data. In some examples, the memory in the processor 110 is a cache memory. This memory can store instructions or data that the processor 110 has just used or is recurring. If the processor 110 needs to use the instruction or data again, it can retrieve it directly from the memory. This avoids repeated accesses, reduces the waiting time of the processor 110, and thus improves the efficiency of the system.

[0140] In this application, a computer program may be stored in the memory to enable a controller or processor to implement the device connection method of this application through an interface or protocol. Exemplarily, the computer program stored in the memory can be used for: performing device authentication and negotiating a session key with other electronic devices; storing the session key; deleting expired session keys; and, during the process of establishing a device connection, first using the stored session key for two-way authentication, and if the authentication is successful, using the stored session key for data encryption and transmission, and if the authentication fails, performing device authentication and negotiating a session key.

[0141] USB port 130 is a USB standard compliant interface, specifically a Mini USB port, Micro USB port, USB Type-C port, etc. USB port 130 can be used to connect a charger to charge electronic device 100, and can also be used for data transfer between electronic device 100 and peripheral devices. It can also be used to connect headphones for audio playback.

[0142] The charging management module 140 receives charging input from a charger, which can be a wireless charger or a wired charger. While charging the battery 142, the charging management module 140 can also supply power to the electronic device via the power management module 141.

[0143] The power management module 141 is used to connect the battery 142, the charging management module 140, and the processor 110. The power management module 141 receives input from the battery 142 and / or the charging management module 140 to power the processor 110, internal memory 121, external memory, display 194, camera 193, and wireless communication module 160, etc.

[0144] The wireless communication function of electronic device 100 can be realized through antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, etc.

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

[0146] The mobile communication module 150 can provide solutions for wireless communication, including 2G / 3G / 4G / 5G, applied to the electronic device 100. The mobile communication module 150 may include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves via antenna 1, and perform filtering, amplification, and other processing on the received electromagnetic waves before transmitting them to a modem processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modem processor and convert it into electromagnetic waves for radiation via antenna 1.

[0147] The wireless communication module 160 can provide solutions for wireless communication applications on the electronic device 100, including wireless local area networks (WLANs) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), and infrared (IR) technologies. The wireless communication module 160 can be one or more devices integrating at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via antenna 2, performs frequency modulation and filtering of the electromagnetic wave signals, and sends the processed signal to processor 110. The wireless communication module 160 can also receive signals to be transmitted from processor 110, perform frequency modulation and amplification, and convert them into electromagnetic waves for radiation via antenna 2.

[0148] Electronic device 100 implements display functions through a GPU, a display screen 194, and an application processor. The GPU is a microprocessor for image processing, connecting the display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations and for graphics rendering.

[0149] The display screen 194 is used to display images, videos, etc. In some embodiments, the electronic device 100 may include one or N display screens 194, where N is a positive integer greater than 1.

[0150] Electronic device 100 can perform shooting functions through ISP, camera 193, video codec, GPU, display 194 and application processor.

[0151] The ISP is used to process data fed back from the camera 193. For example, when taking a picture, the shutter is opened, and light is transmitted through the lens to the camera's photosensitive element. The light signal is converted into an electrical signal, and the camera's photosensitive element transmits the electrical signal to the ISP for processing, converting it into an image visible to the naked eye.

[0152] Camera 193 is used to capture still images or videos. In some embodiments, electronic device 100 may include one or N cameras 193, where N is a positive integer greater than 1.

[0153] Digital signal processors (DSPs) are used to process digital signals. Besides digital image signals, they can also process other digital signals. For example, when electronic device 100 selects a frequency, the DSP performs Fourier transforms on the frequency energy.

[0154] An NPU (Neural Processing Unit) is a computational processor for neural networks (NNs). By borrowing the structure of biological neural networks, such as the transmission patterns between neurons in the human brain, it can rapidly process input information and continuously learn on its own. NPUs enable intelligent cognitive applications in electronic devices, such as image recognition, facial recognition, speech recognition, and text understanding.

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

[0156] Internal memory 121 can be used to store computer executable program code, which includes instructions. Processor 110 executes various functional applications and data processing of electronic device 100 by running the instructions stored in internal memory 121. Internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback, image playback, etc.), etc. The data storage area may store data created during the use of electronic device 100 (such as audio data, phonebook, etc.). Furthermore, internal memory 121 may 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.

[0157] Electronic device 100 can implement audio functions, such as music playback and recording, through audio module 170, speaker 170A, receiver 170B, microphone 170C, headphone jack 170D, and application processor.

[0158] The audio module 170 is used to convert digital audio information into analog audio signals for output, and also to convert analog audio input into digital audio signals. The audio module 170 can also be used for encoding and decoding audio signals. In some embodiments, the audio module 170 may be located in the processor 110, or some functional modules of the audio module 170 may be located in the processor 110.

[0159] The speaker 170A, also known as a "loudspeaker," is used to convert audio electrical signals into sound signals. The electronic device 100 can listen to music or make hands-free calls through the speaker 170A.

[0160] The receiver 170B, also known as the "earpiece," is used to convert audio electrical signals into sound signals. When the electronic device 100 receives a telephone call or voice message, the receiver 170B can be brought close to the ear to hear the voice.

[0161] Microphone 170C, also known as a "microphone" or "voice transducer," is used to convert sound signals into electrical signals. When making a phone call or sending a voice message, the user can speak by bringing their mouth close to microphone 170C, inputting the sound signal into microphone 170C.

[0162] The 170D headphone jack is used to connect wired headphones.

[0163] In this application, the speaker 170A, receiver 170B, and microphone 170C are all optional.

[0164] The sensor module 180 may include pressure sensors, gyroscope sensors, barometric pressure sensors, magnetic sensors, accelerometers, gravity sensors, distance sensors, proximity sensors, fingerprint sensors, temperature sensors, touch sensors, ambient light sensors, bone conduction sensors, angle sensors, etc.

[0165] Buttons 190 include a power button, volume buttons, etc. Motor 191 can generate vibration feedback. Indicator 192 can be an indicator light, used to indicate charging status, battery level changes, and also to indicate messages, missed calls, notifications, etc.

[0166] The SIM card interface 195 is used to connect a SIM card. The SIM card can be inserted into or removed from the SIM card interface 195 to make contact with and detach from the electronic device 100. The electronic device 100 can support one or N SIM card interfaces, where N is a positive integer greater than 1. The electronic device 100 interacts with the network through the SIM card to achieve functions such as calls and data communication. In some examples, the electronic device 100 uses an eSIM, i.e., an embedded SIM card. The eSIM card can be embedded in the electronic device 100 and cannot be removed from it.

[0167] The software system of electronic device 100 can adopt a layered architecture, event-driven architecture, microkernel architecture, microservice architecture, or cloud architecture. This application embodiment uses a layered architecture. Taking the system as an example, the software structure of electronic device 100 is illustrated.

[0168] Figure 4 An exemplary schematic diagram of the software structure of an electronic device 100 is shown.

[0169] A layered architecture divides software into several layers, each with a clear role and function. Layers communicate with each other through software interfaces. In some embodiments, [the following is omitted as the text is incomplete and likely refers to a specific implementation or feature]. The system is divided into four layers, from top to bottom: application layer, application framework layer, system library, and kernel layer.

[0170] The application layer can include a series of application packages.

[0171] like Figure 4 As shown, the application package may include applications such as camera, gallery, calendar, call, map, navigation, WLAN, Bluetooth, music, SMS, and data sharing applications.

[0172] The data sharing application can be an application used to share data such as images, videos, audio, and text files. In some embodiments, the data sharing application can share data from electronic device 100 with other electronic devices. The data sharing application can also share data within one application on electronic device 100 with other users through another application. The data sharing application can be a standalone application. Alternatively, it can be a sub-application integrated into other applications (e.g., a gallery application, a music application, a video application, etc.). This application does not limit the type and implementation of the data sharing application. For example, the data sharing application can be an application such as Huawei Share.

[0173] The application framework layer provides APIs and a programming framework for applications within the application layer. The application framework layer includes some predefined functions.

[0174] like Figure 4 As shown, the application framework layer may include a window manager, content provider, view system, phone manager, resource manager, notification manager, activity manager, sharing service, etc.

[0175] The window manager is used to manage windowed applications. It can retrieve screen size, determine the presence of a status bar, lock the screen, and capture screenshots, among other things.

[0176] Content providers store and retrieve data, making that data accessible to applications. This data may include videos, images, audio, made and received phone calls, browsing history and bookmarks, phone books, etc.

[0177] A view system includes visual controls, such as controls for displaying text and controls for displaying images. View systems can be used to build applications. A display interface can consist of one or more views. For example, a display interface including a text notification icon could include views for displaying text and views for displaying images.

[0178] The phone manager is used to provide communication functions for electronic device 100. For example, it manages call status (including connection and disconnection).

[0179] The file explorer provides applications with various resources, such as localized strings, icons, images, layout files, video files, and more.

[0180] The notification manager allows applications to display notifications in the status bar (such as the pull-down notification bar). It can be used to convey informational messages and can disappear automatically after a short pause without user interaction. For example, the notification manager can be used to notify users of download completion or message alerts. The notification manager can also display notifications as icons or scrolling text in the top status bar, such as notifications from background applications, or as dialog boxes on the screen. Examples include displaying text messages in the status bar, emitting sounds, vibrating electronic devices, and flashing indicator lights.

[0181] The Activity Manager is responsible for managing activities, including starting, switching, and scheduling components in the system, as well as managing and scheduling applications. The Activity Manager can be called by upper-level applications to open the corresponding activities.

[0182] The sharing service can be used for device authentication, negotiation and management of session keys, session establishment, and transmission of business data (e.g., text data, image data, audio streams, video streams, etc.). In some embodiments, the sharing service can also authenticate with other electronic devices based on stored session keys to determine whether renegotiating the session key is necessary. If authentication is successful, the sharing service can send the corresponding session key to the data sharing application. The data sharing application can then encrypt the data to be transmitted based on this session key and send it to the data receiver corresponding to the session key. This eliminates the need for the sharing service to renegotiate session keys with other electronic devices, simplifying the process for non-first-time connections and improving device connection speed. The aforementioned sharing service can also be referred to as a data transmission service, streaming service, etc.

[0183] System libraries can include multiple functional modules. For example: surface manager, media libraries, 3D graphics processing libraries (e.g., OpenGL ES), 2D graphics engines (e.g., SGL), etc.

[0184] The Surface Manager is used to manage the display subsystem and provides the blending of 2D and 3D layers for multiple applications.

[0185] The media library supports playback and recording of various common audio and video formats, as well as still image files. It supports multiple audio and video encoding formats, such as MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG.

[0186] The 3D graphics processing library is used to implement 3D graphics drawing, image rendering, compositing, and layer processing.

[0187] A 2D graphics engine is a graphics engine for 2D drawing.

[0188] The kernel layer is the layer between hardware and software. The kernel layer contains at least the display driver, camera driver, audio driver, and sensor driver.

[0189] Figure 5 An exemplary schematic diagram of the software structure of another electronic device 100 is shown.

[0190] like Figure 5 As shown, the software architecture of electronic device 100 can be implemented based on a distributed soft bus architecture. The distributed soft bus architecture, from top to bottom, can include applications, soft bus, device authentication module, and communication module.

[0191] Applications may include, but are not limited to: file sharing, tap-to-pay, smart home, smart office, smart travel, sports and health, etc.

[0192] A soft bus may include a device discovery module, a device connection module, a device networking module, and a data transmission module.

[0193] The device discovery module can be used to discover the existence of distributed devices in the vicinity using soft bus discovery technology. A device can be the discoverer, the active discoverer, or both. The device discovery module supports discovering devices via different media such as Wi-Fi, Bluetooth, and Ethernet; it supports selecting the appropriate discovery medium based on the capabilities of different devices; and it supports providing appropriate discovery strategies such as discovery frequency and scan cycle based on device characteristics and business needs.

[0194] The device connection module can be used to connect peripheral distributed devices using soft bus connection technology. Based on the capabilities of the distributed devices and business requirements, the device connection module can select appropriate communication media and connection technologies to establish communication links, providing the foundation for subsequent networking and transmission.

[0195] The device networking module can be used to connect distributed devices with different capabilities and characteristics into a network based on soft bus networking technology. This allows the distributed device network to be not limited to a single or one-to-one connection, but rather to form a dynamic network connecting devices involved in multiple scenarios. In this network, the communication and service capabilities of each device can be effectively managed. When a service requires it, the device networking module can provide the necessary device capability information to support the establishment of service channels. In some embodiments, the device networking module can manage the online device list of electronic devices 100. The online device list can be referred to the description in the foregoing embodiments. When a newly discovered electronic device is authenticated and the authentication is successful, the device networking module can add the electronic device to the online device list of electronic devices 100. When an electronic device in the online device list is authenticated and the authentication fails, the device networking module can remove the electronic device from the online device list. The device networking module can detect whether an electronic device is online based on the online device list.

[0196] The data transmission module can be used to transmit service data for distributed services (e.g., data sharing services) based on soft bus transmission technology. In some embodiments, the data transmission module can establish a session with other electronic devices and encrypt the data transmission based on a negotiated session key.

[0197] The device authentication module can be used to authenticate other electronic devices to verify whether they are trusted devices. During the authentication process, the device authentication module can negotiate a session key with other electronic devices. In some embodiments, when a device networking module in a soft bus performs device networking, the device networking module can call the device authentication module to perform device authentication. If the device authentication is successful, the module confirms the device is online, thus completing the networking. The device authentication module can send the negotiated session key to the aforementioned data transmission module, so that the data transmission module can use the session key for data transmission, ensuring the security of data transmission.

[0198] The device authentication module can perform device authentication on other devices discovered by electronic device 100 based on the soft bus. The device authentication module can use... Device authentication algorithms are used to achieve secure device interconnection. In some embodiments, the device authentication module may also use methods such as the CCMP authentication algorithm for device authentication. This application does not limit the method used by the device authentication module for device authentication.

[0199] Communication modules support device discovery, device connection, device networking, and data transmission for soft buses. Communication modules include, but are not limited to: Bluetooth, WLAN, Ethernet, infrared, power line communication (PLC), NFC, ZigBee, UWB, etc.

[0200] Figures 6A to 6C The illustrations are schematic diagrams of some data sharing scenarios provided in the embodiments of this application.

[0201] like Figure 6A As shown, electronic device 201 can display user interface 610. The device account logged in on electronic device 201 can be device account 1. User interface 610 can be the user interface of a gallery application. User interface 610 may include images 611 and a sharing control 612. In response to an operation on the sharing control 612, electronic device 201 can display... Figure 6B The user interface shown is 620.

[0202] like Figure 6B As shown, the user interface 620 may include an image 621, device options 622, device options 623, and an application options area 624.

[0203] Image 621 could be... Figure 6A The thumbnail of image 611 shown.

[0204] Device option 622 can be used to share the selected image (e.g., image 621) to the electronic device corresponding to device option 622. For example, the electronic device corresponding to device option 622 could be an electronic device named "Zhang San's Tablet". In some embodiments, the electronic device corresponding to device option 622 and electronic device 201 can be devices under the same account.

[0205] Device option 623 can be used to share the selected image to the electronic device corresponding to device option 623. For example, the electronic device corresponding to device option 623 could be an electronic device named "Li Si's Mobile Phone," which could be one of the aforementioned devices. Figure 2 The electronic device 202 shown. The device account logged in on electronic device 202 can be device account 2.

[0206] In some embodiments, in response to Figure 6AThe operation of the sharing control 612 shown allows the electronic device 201 to search for nearby electronic devices capable of receiving image sharing. Specifically, the electronic device 201 can search for electronic devices that have previously shared images through the gallery application, as well as electronic devices that have not been connected. This embodiment does not limit the method by which the electronic device 201 searches for devices. The electronic device 201 can display device options (e.g., device option 622, device option 623, etc.) corresponding to the found electronic devices on the user interface 620, allowing the user to select the target device for image sharing.

[0207] The application options area 624 may include one or more application options. An application option can be used to share the selected image with other users through the application corresponding to the application option. The electronic device 201 can find the applications in the electronic device 201 that can share images, and then display the application options corresponding to these applications in the application options area 624.

[0208] like Figure 6B As shown, in response to an operation on device option 623, electronic device 201 can share the selected image with the electronic device corresponding to device option 623 (e.g., electronic device 202). If electronic device 201 and electronic device 202 are not currently connected, electronic device 201 can establish a communication connection with electronic device 202 and then send the shared image to electronic device 202.

[0209] In some embodiments, since electronic device 201 and electronic device 202 are devices with different accounts, when electronic device 202 receives a message from device 201 for sharing pictures, it can display... Figure 6C The prompt box 631 shown asks the user whether they want to accept image sharing.

[0210] like Figure 6C As shown, the prompt box 631 may include an image 631A, prompt content 631B, a refuse control 631C, and an agree control 631D.

[0211] Image 631A could be a thumbnail of the image to be shared, for example... Figure 6A The thumbnail of image 611 shown.

[0212] The prompt content 631B can be used to ask the user whether they wish to accept image sharing. This application embodiment does not limit the prompt content 631B.

[0213] The rejection control 631C can be used to reject image sharing from electronic device 201.

[0214] The consent control 631D can be used to receive image sharing from electronic device 201. In response to an operation on the consent control 631D, electronic device 202 can retrieve and save the image shared by electronic device 201. For example, a gallery application in electronic device 202 can save the image shared by electronic device 201. Thus, the user can view the image shared by electronic device 201 in the gallery application of electronic device 202.

[0215] In some embodiments, if electronic device 201 sends a request to a device with the same account (e.g., the aforementioned...) Figure 2 The electronic device 203 shown can share pictures. The electronic device 203 can directly receive and save the pictures shared by the electronic device 201 without displaying them. Figure 6C The prompt box 631 shown simplifies the data sharing process for users. The gallery application in electronic device 203 can save images shared by electronic device 201. Users can view the images shared by electronic device 201 in the gallery application of electronic device 203.

[0216] The scenarios for sharing other types of data (e.g., audio, video, text files, etc.) on electronic device 201 can be referenced from the scenarios for sharing images described above, and will not be repeated here.

[0217] Based on the above data sharing scenario, the device connection method provided in the embodiments of this application is described below.

[0218] Figure 7A An exemplary flowchart of a method for connecting devices with different accounts is shown.

[0219] S711, Electronic device 201 receives an operation to share data 1 to electronic device 202.

[0220] Data 1 can be of the following types, including but not limited to: images, audio, video, text files, etc. For example, data 1 is as described above. Figure 6A Image 611 is shown. The operations described above for sharing data 1 may include... Figure 6B The operation of device option 623 is shown.

[0221] In the scenario where electronic device 201 shares data 1 with electronic device 202, electronic device 201 is the data sender and electronic device 202 is the data receiver.

[0222] S712, Electronic Device 201 and Electronic Device 202 establish a device authentication channel.

[0223] S713, electronic devices 201 and 202 complete device authentication based on the device authentication channel.

[0224] The AuthChannel can be used to transmit messages for device authentication between electronic device 201 and electronic device 202.

[0225] In some embodiments, electronic devices 201 and 202 may use the CCMP authentication algorithm for device authentication. This application does not limit the method for device authentication between devices with different accounts.

[0226] During device authentication, electronic devices 201 and 202 can negotiate a session key. Specific methods for negotiating the session key will be discussed later. Figure 7B The method is described in the diagram. We will not elaborate further here.

[0227] S714, Electronic device 201 and electronic device 202 create a session for transmitting data.

[0228] After electronic devices 201 and 202 complete device authentication, they create a session for data transmission.

[0229] S715, Electronic device 201 sends data 1 to electronic device 202.

[0230] Electronic device 201 can encrypt data 1 using the session key negotiated with electronic device 202 in step S713 above, and send the encrypted data 1 to electronic device 202. When receiving the encrypted data 1, electronic device 202 can decrypt it using the session key negotiated with electronic device 201 in step S713 above, and obtain data 1.

[0231] Figure 7B An exemplary flowchart illustrates a method for negotiating session keys between devices with different account numbers.

[0232] Electronic device 201 includes data sharing application 1. Electronic device 202 includes data sharing application 2. Data sharing application 1 and data sharing application 2 can be the same application or different applications. Figure 7A The data shown, 1, can be shared by data sharing application 1 to data sharing application 2.

[0233] In execution Figure 7A During step S713 shown, electronic devices 201 and 202 can proceed according to... Figure 7B The method shown negotiates the session key. Specifically:

[0234] S721, Data Sharing Application 1 obtains public key 1.

[0235] In some embodiments, the electronic device 201 may store a key pair, including a public key 1 and a private key 1. The private key 1 can be used to decrypt data encrypted using the public key 1. The key pair may be generated based on an asymmetric encryption algorithm. For example, the asymmetric encryption algorithm may be the RSA (Rivest–Shamir–Adleman) encryption algorithm. This application embodiment does not limit the method for generating the key pair. Furthermore, after the electronic device 201 is restored to factory settings, the key pair can be updated.

[0236] S722, Data sharing application 1 sends public key 1 to data sharing application 2.

[0237] In some embodiments, in addition to sending public key 1, data sharing application 1 can also send a certificate associated with public key 1. This certificate can be used to identify the sender as electronic device 201. Thus, data sharing application 2 can verify the sender's identity based on the certificate.

[0238] S723, Data Sharing Application 2 obtains public key 2.

[0239] In some embodiments, the electronic device 202 may store a key pair, including a public key 2 and a private key 2. The private key 2 can be used to decrypt data encrypted using the public key 2. The key pair can be updated after the electronic device 202 is reset to factory settings.

[0240] S724, Data sharing application 2 sends public key 2 to data sharing application 1.

[0241] In some embodiments, in addition to sending public key 2, data sharing application 2 can also send a certificate associated with public key 2. This certificate can be used to identify the sender as data sharing application 2. Thus, data sharing application 1 can verify the sender's identity based on the certificate.

[0242] S725, Data sharing application 1 uses public key 2 to encrypt random number 1 and key k0 to obtain encrypted data 1.

[0243] Random number 1 can be randomly generated by the data sharing application 1 using the corresponding random algorithm.

[0244] The key k0 may be generated by the data sharing application 1 using an encryption algorithm. In some embodiments, the key k0 may be generated based on the device identifier (ID) and account ID of the electronic device 201. For example, the key k0 may include the hashed and truncated data of the device ID of the electronic device 201 and the hashed and truncated data of the account ID of the device account in the electronic device 201. The embodiments of this application do not limit the length of the hash truncation.

[0245] In some embodiments, the device ID can be a unique device identifier (UDID).

[0246] S726, Data sharing application 1 sends encrypted data 1 to data sharing application 2.

[0247] S727, Data sharing application 2 uses the private key 2 corresponding to public key 2 to decrypt encrypted data 1, and obtains random number 1 and key k0.

[0248] S728, Data Sharing Application 2 uses random number 1 and key k0 to generate session key 1.

[0249] In some embodiments, during the negotiation session between applications on devices with different accounts, a session key (e.g., session key 1) can be generated using the 256-bit Advanced Encryption Standard (AES-256) algorithm and a derived algorithm from the HarmonyOS Universal Key Store (HUKS). This application does not limit the method of generating session key 1.

[0250] S729. Data sharing application 2 uses key k0 to encrypt session key 1 to obtain encrypted data 2. It then uses public key 1 to encrypt encrypted data 2 and random number 1 to obtain encrypted data 3.

[0251] S730, Data Sharing Application 2 sends encrypted data 3 to Data Sharing Application 1.

[0252] S731. Data sharing application 1 uses the private key 1 corresponding to public key 1 to decrypt encrypted data 3, obtaining encrypted data 2 and random number 1. It uses key k0 to decrypt encrypted data 2, obtaining session key 1, and verifies random number 1.

[0253] Successful verification of random number 1 indicates successful session key negotiation. Then, data sharing application 1 can use session key 1 to encrypt the data to be shared, such as data 1, and send the encrypted data 1 to electronic device 202.

[0254] As can be seen, during the key negotiation process described above, the session key can be encrypted and transmitted using the RSA encryption algorithm.

[0255] It should be noted that electronic device 202 also includes data sharing application 2'. If data sharing application 1 in electronic device 201 sends data to data sharing application 2' in electronic device 202, data sharing application 1 and data sharing application 2' can also negotiate the session key.

[0256] In some embodiments, each time electronic devices 201 and 202 transmit data, they need to follow the instructions. Figure 7A and Figure 7B The method shown establishes a communication connection and negotiates a session key during the connection establishment process. This communication connection process is time-consuming. Users of electronic devices 201 and 202 must wait a considerable amount of time each time they share data, resulting in a poor user experience.

[0257] In some embodiments, devices with different account names can negotiate and save the session key. When data needs to be transmitted between devices with different account names, they can look up the historical session key and perform two-way authentication based on it. If the authentication is successful, the devices with different account names can use the historical session key to encrypt and transmit data.

[0258] The session keys negotiated between electronic devices and devices with different accounts can be found in Table 1 below. Table 1 can also be called the inter-account session key data table.

[0259]

[0260] Table 1

[0261] The receiving device ID can refer to the device ID of the communication peer device, such as the UDID of the communication peer device.

[0262] The receiving end account ID can refer to the account ID of the logged-in device account on the communication peer device.

[0263] The sending application identifier can refer to the identifier of the application in the local communication device that needs to transmit data with the peer communication device.

[0264] The receiving application identifier can refer to the identifier of the application that transmits data with the communicating end in the peer end.

[0265] The remaining validity period refers to the remaining time that an electronic device can store a session key. A remaining validity period of 0 indicates that the session key has timed out. When the remaining validity period of a session key is 0, the electronic device can delete the session key.

[0266] In some embodiments, the validity period of the session key can be preset. For example, the validity period of the session key is 7 days. The electronic device can determine the remaining validity period of the session key based on the storage time of the session key.

[0267] For example, in Table 1, the remaining validity period of Session Key 1 is 2 days. The device ID associated with Session Key 1 is Device ID1. The receiving account ID associated with Session Key 1 is Account ID1. The sending application identifier associated with Session Key 1 is the identifier of Application 1. The receiving application identifier associated with Session Key 1 is the identifier of Application 2. That is to say, Session Key 1 is the session key used by Application 1 in the electronic device storing Table 1 and Application 2 in the electronic device with Device ID1 and Account ID1 for encrypted data transmission. Other session keys in Table 1 can be found in the above description of Session Key 1.

[0268] As can be seen, electronic devices can use the receiver device ID, receiver account ID, sender application, and receiver application to determine whether they have stored the historical session key corresponding to the communication peer device.

[0269] Not limited to the data shown in Table 1, electronic devices may store more or less data when storing session keys negotiated with devices on different accounts.

[0270] In some embodiments, if an electronic device negotiates a session key with an electronic device that is not logged in with a device account, the receiving account ID associated with the session key in the cross-account session key data table is empty when the electronic device stores the session key.

[0271] In some embodiments, the electronic device may also store the public key of the receiving device when storing the session key. It is understood that the public key of an electronic device can remain unchanged unless it has been factory reset. Therefore, the electronic device can also use the public key of the receiving device, the receiving account ID, the sending application, and the receiving application to determine whether it has stored a historical session key corresponding to the communication peer device.

[0272] Optionally, the electronic device can also record the storage time of the session key when storing it, so that the session key can be deleted when the storage time expires.

[0273] Figure 8 An exemplary flowchart of another method for connecting devices with different accounts is shown.

[0274] like Figure 8 As shown, device account 1 is logged in on electronic device 201. Electronic device 201 includes data sharing application 1 and sharing service 1. Device account 2 is logged in on electronic device 202. Electronic device 202 includes data sharing application 2 and sharing service 2. Electronic devices 201 and 202 can be configured according to... Figure 8 The method shown establishes a connection and performs data transmission.

[0275] S811, Data sharing application 1 receives an operation to share data 1 to electronic device 202.

[0276] The S811 can be referenced as described above. Figure 7A Step S711 is shown.

[0277] S812, Data sharing application 1 requests to share service 1 to connect with electronic device 202.

[0278] S813, Shared Service 1 and Shared Service 2 establish a device authentication channel.

[0279] In some embodiments, sharing service 1 can obtain the device ID of electronic device 201 and the account ID of device account 1, and send them to sharing service 2. Sharing service 2 can obtain the device ID of electronic device 202 and the account ID of device account 2, and send them to sharing service 1.

[0280] S814, Share service 1 queries whether the session key corresponding to electronic device 202 and device account 2 is stored.

[0281] In some embodiments, the electronic device 201 stores a cross-account session key data table. This cross-account session key data table includes session keys negotiated by the electronic device 201 during data transmission with devices of different accounts, and which are still valid. The cross-account session key data table can be referenced from Table 1 above. The sharing service 1 can query whether a session key corresponding to the electronic device 202 and device account 2 is stored based on the device ID of the electronic device 202, the account ID of device account 2, the identifier of data sharing application 1, and the identifier of data sharing application 2.

[0282] If the session key in the session key data table of the different account of electronic device 201 contains the following session keys: the device ID associated with the session key matches the device ID of electronic device 202, the account ID associated with the session key matches the account ID of device account 2, the sender application identifier associated with the session key matches the identifier of data sharing application 1, and the receiver application identifier associated with the session key matches the identifier of data sharing application 2, then the session key is the session key corresponding to electronic device 202 and device account 2.

[0283] If the session key corresponding to electronic device 202 and device account 2 is not stored, sharing service 1 can perform the following step S815.

[0284] If the session key corresponding to electronic device 202 and device account 2 is stored, the sharing service 1 can perform the following step S816.

[0285] S815, Sharing Service 1 Notification Data Sharing Application 1 Negotiating Session Key.

[0286] If the session key corresponding to electronic device 202 and device account 2 is not stored, data sharing application 1 can negotiate the session key with data sharing application 2. The method for negotiating the session key can be referred to the above. Figure 7B The method is shown. Once a session key is negotiated, electronic devices 201 and 202 can store the session key in their respective heterogeneous account session key data tables.

[0287] S816. Sharing service 1 uses session key k1 to encrypt the device ID of electronic device 201 and the account ID of device account 1 to obtain encrypted data d1. Session key k1 is the session key corresponding to electronic device 202 and device account 2.

[0288] In some embodiments, sharing service 1 can hash and truncate the device ID of electronic device 201 and the account ID of device account 1. Sharing service 1 can use session key k1 to encrypt the hashed and truncated data of the device ID of electronic device 201 and the account ID of device account 1 to obtain encrypted data d1. This can reduce the amount of data transmission and improve the efficiency of two-way authentication between electronic device 201 and electronic device 202 using historical session keys. Alternatively, sharing service 1 can also use session key k1 to encrypt the complete device ID of electronic device 201 and the complete account ID of device account 1 to obtain encrypted data d1.

[0289] S817, Sharing service 1 sends public key 1 and encrypted data d1 to sharing service 2.

[0290] Electronic device 201 stores public key 1 and private key 1. Sharing service 1 can obtain public key 1 and send public key 1 and encrypted data d1 to sharing service 2. Optionally, sharing service 1 can also send the certificate corresponding to public key 1 to sharing service 2 so that sharing service 2 can determine that the sender of the data is electronic device 201. The aforementioned public key 1 and encrypted data d1 can be transmitted based on a device authentication channel.

[0291] In some embodiments, sharing service 1 may perform TLV (Tag-Length-Value) encoding on encrypted data d1 and then send the TLV-encoded encrypted data d1 to sharing service 2.

[0292] S818, Share service 2 queries whether the session key corresponding to electronic device 201 and device account 1 is stored.

[0293] In some embodiments, the electronic device 202 stores a cross-account session key data table. This cross-account session key data table includes session keys negotiated by the electronic device 202 during data transmission with devices of different accounts that are still valid. The cross-account session key data table can be referenced from Table 1 above. The sharing service 2 can query whether a session key corresponding to the electronic device 201 and device account 1 is stored based on the device ID of the electronic device 201, the account ID of device account 1, the identifier of data sharing application 1, and the identifier of data sharing application 2.

[0294] If the session key in the session key data table of the different account of electronic device 202 contains the following session keys: the device ID associated with the session key matches the device ID of electronic device 201, the account ID associated with the session key matches the account ID of device account 1, the sender application identifier associated with the session key matches the identifier of data sharing application 2, and the receiver application identifier associated with the session key matches the identifier of data sharing application 1, then the session key is the session key corresponding to electronic device 201 and device account 1.

[0295] If the session key corresponding to electronic device 201 and device account 1 is stored, the sharing service 2 can perform the following step S819.

[0296] If the session key corresponding to electronic device 201 and device account 1 is not stored, the sharing service 2 can perform the following step S820.

[0297] S819, Sharing service 2 determines whether the session key k2 can be successfully decrypted to the encrypted data d1. The session key k2 is the session key corresponding to electronic device 201 and device account 1.

[0298] Sharing service 2 can decrypt the encrypted data d1 using session key k2 and match it with the device ID of electronic device 201 and the account ID of device account 1. If the match is successful, decryption is successful. If the match fails, decryption fails.

[0299] If the encrypted data d1 is successfully decrypted, the sharing service 2 can perform the following step S821.

[0300] If decryption of encrypted data d1 fails, sharing service 2 can perform the following step S820.

[0301] S820, Sharing Service 2 sends a decryption failure message to Sharing Service 1, and Data Sharing Application 1 and Data Sharing Application 2 negotiate the session key.

[0302] If electronic device 202 does not store the session key corresponding to electronic device 201 and device account 1, or if the session key k1 stored in electronic device 202 corresponding to electronic device 201 and device account 1 fails to decrypt the encrypted data d1, sharing service 2 can send a decryption failure message to sharing service 1.

[0303] Based on the decryption failure message, sharing service 1 can notify data sharing application 1 to negotiate the session key. Data sharing application 1 can then negotiate the session key with data sharing application 2; the method for negotiating the session key can be found above. Figure 7B The method is shown. Once a session key is negotiated, electronic devices 201 and 202 can store the session key in their respective heterogeneous account session key data tables.

[0304] In some embodiments, if the electronic device 202 does not store the session key corresponding to the electronic device 201 and device account 1, or if the session key k1 stored in the electronic device 202 fails to decrypt the encrypted data d1, the sharing service 2 may not send a response message to the sharing service 1. If the sharing service 1 does not receive a response message from the sharing service 2 within a preset time period after executing step S817, the sharing service 1 may notify the data sharing application 1 to negotiate the session key.

[0305] S821, Sharing service 2 uses session key k2 to encrypt the device ID of electronic device 202 and the account ID of device account 2 to obtain encrypted data d2.

[0306] The fact that sharing service 2 successfully decrypted the encrypted data d1 using session key k2 indicates that session key k1 and session key k2 are the same. That is, electronic devices 201 and 202 can achieve encrypted data transmission based on session key k1 (i.e., session key k2).

[0307] In some embodiments, sharing service 2 can hash and truncate the device ID of electronic device 202 and the account ID of device account 2. Sharing service 2 can use session key k2 to encrypt the hashed and truncated data of the device ID of electronic device 202 and the account ID of device account 2, obtaining encrypted data d2. This can reduce the amount of data transmission and improve the efficiency of two-way authentication between electronic device 201 and electronic device 202 using historical session keys. Alternatively, sharing service 2 can also use session key k2 to encrypt the complete device ID of electronic device 202 and the complete account ID of device account 2, obtaining encrypted data d2.

[0308] S822, Sharing service 2 sends public key 2 and encrypted data d2 to sharing service 1.

[0309] Electronic device 202 stores public key 2 and private key 2. Sharing service 2 can obtain public key 2 and send public key 2 and encrypted data d2 to sharing service 1. Optionally, sharing service 2 can also send the certificate corresponding to public key 2 to sharing service 1 so that sharing service 1 can determine that the sender of the data is electronic device 202. The aforementioned public key 2 and encrypted data d2 can be transmitted based on a device authentication channel.

[0310] In some embodiments, sharing service 2 may perform TLV encoding on encrypted data d2 and then send the TLV-encoded encrypted data d2 to sharing service 1.

[0311] S823, Sharing service 1 successfully decrypted encrypted data d2 using session key k1.

[0312] Sharing service 1 can decrypt the encrypted data d2 using session key k1 and match it with the device ID of electronic device 202 and the account ID of device account 2. If the match is successful, the decryption is successful.

[0313] In some embodiments, not limited to device ID and account ID, the encrypted data d1 and encrypted data d2 can also be generated based on random numbers. Specifically, sharing service 1 can generate random number 2 and encrypt it using session key k1 to generate encrypted data d1. Sharing service 1 can send encrypted data d1 to sharing service 2. Sharing service 2 can decrypt encrypted data d1 using session key k2 and encrypt the decrypted data using session key k2 to obtain encrypted data d2. Optionally, sharing service 2 can add a preset value (e.g., add 1 or 2, etc.) to the data obtained by decrypting encrypted data d1 using session key k2, and then encrypt the data with the added preset value using session key k2 to obtain encrypted data d2. Sharing service 2 can send encrypted data d2 to sharing service 1. Sharing service 1 can decrypt encrypted data d2 using session key k1. The data obtained by sharing service 1 in decrypting encrypted data d2 is the aforementioned random number 2 (or random number 2 plus a preset value), which indicates that sharing service 1 has successfully decrypted the aforementioned encrypted data d1, and sharing service 2 has successfully decrypted the aforementioned encrypted data d2. Then, electronic devices 201 and 202 can execute subsequent steps S824 to S826.

[0314] It can be seen that sharing service 2 successfully decrypted the encrypted data d1 using session key k2, and sharing service 1 successfully decrypted the encrypted data d2 using session key k1, indicating that the two-way authentication between electronic device 201 and electronic device 202 was successful. Therefore, data sharing application 1 and data sharing application 2 can achieve encrypted data transmission based on session key k1 (i.e., session key k2).

[0315] S824, Share Service 1 and Share Service 2 establish Session 1.

[0316] In some embodiments, establishing session 1 may include establishing a data transmission channel for transmitting business data.

[0317] S825, Sharing service 1 sends a message to data sharing application 1 to indicate that session 1 has been created.

[0318] S826. Data sharing application 1 encrypts data 1 using session key k1 and sends it to data sharing application 2.

[0319] Based on session 1, data sharing application 1 can send data 1, which is encrypted via session key k1, to data sharing application 2.

[0320] When encrypted data 1 is received, data sharing application 2 can decrypt it using session key k2 to obtain data 1.

[0321] As can be seen from the above method, if both electronic devices 201 and 202 store a session key that they have previously negotiated and is still valid, then electronic devices 201 and 202 can use this session key to achieve encrypted data transmission without needing to renegotiate the session key. This can improve the speed of device connection and enhance the user's data sharing experience.

[0322] Furthermore, the session key used to encrypt data during transmission is a session key that electronic devices 201 and 202 have previously negotiated and is still valid. Therefore, the above method can ensure the security of data transmission between electronic devices 201 and 202.

[0323] In some embodiments, if at least one of electronic devices 201 and 202 is not logged into a device account, then the above... Figure 8 In the steps of the method shown that require the account ID of the relevant device account, the account ID can be empty.

[0324] For example, device account 1 is logged in on electronic device 201, while device account 202 is not logged in. Electronic devices 201 and 202 remain devices with different accounts. In the above... Figure 8 In step S814, as shown, sharing service 1 can query whether electronic device 201 stores a session key corresponding to electronic device 202 with an empty account ID. That is, sharing service 1 can query the session key based on the device ID of electronic device 202, the identifier of data sharing application 1, and the identifier of data sharing application 2, and determine whether the receiving end account ID associated with that session key is empty. In the above... Figure 8In step S821 shown, sharing service 2 can use session key k2 to encrypt the device ID of electronic device 202, obtain the corresponding encrypted data, and send it to sharing service 1.

[0325] Alternatively, device 201 may not have a logged-in device account, while device 202 may have a logged-in device account 1. Devices 201 and 202 remain devices with different accounts. (The above...) Figure 8 In step S816 shown, sharing service 1 can use session key k1 to encrypt the device ID of electronic device 201, obtain the corresponding encrypted data, and send it to sharing service 2. In the above... Figure 8 In step S818, the sharing service 2 can query whether the electronic device 202 stores a session key corresponding to the electronic device 201 whose account ID is empty. That is, the sharing service 2 can query the session key based on the device ID of the electronic device 201, the identifier of the data sharing application 1, and the identifier of the data sharing application 2, and determine whether the receiving end account ID associated with the session key is empty.

[0326] In some embodiments, when an electronic device detects a change in the logged-in device account on a peer device, the electronic device can delete all session keys corresponding to the peer device with the changed device account from its stored cross-account session key data table. Furthermore, the electronic device with the changed device account can delete all its stored session keys. Changes in the logged-in device account on an electronic device can include: switching from one device account to another, changing from never having logged in with a device account to having logged in with a device account, and changing from having logged in with a device account to not having logged in with a device account. During the process of switching the logged-in device account on an electronic device, the electronic device can first log out of the currently logged-in device account and then log in with the other device account. When an electronic device logs out of the currently logged-in device account, other electronic devices can delete the session keys corresponding to the electronic device that logged out of the device account.

[0327] For example, the currently logged-in device account of electronic device 202 is device account 2. Electronic device 201 can query the session key associated with the device ID of electronic device 202 in its stored cross-account session key data table. If the account ID associated with the session key associated with the device ID of electronic device 202 is not the account ID of device account 2, then electronic device 201 can delete all session keys associated with the device ID of electronic device 202.

[0328] Understandably, due to changes in the device account logged into electronic device 202, the session key previously negotiated between electronic devices 201 and 202, even if it hasn't expired, is no longer usable. Therefore, electronic device 201 can delete the session key associated with electronic device 202 and directly renegotiate the session key when connecting to electronic device 202 subsequently. This avoids using the aforementioned expired but unusable session key when connecting to electronic device 202 in subsequent connections. Figure 8 If the identity verification fails, the session key will be negotiated again.

[0329] Figure 9 An exemplary flowchart of a method for connecting devices with the same account is shown.

[0330] like Figure 9 As shown, device account 1 is logged in on electronic device 201. Electronic device 201 includes data sharing application 1 and a soft bus. Device account 1 is logged in on electronic device 203. Electronic device 203 includes data sharing application 3 and a soft bus. Electronic devices 201 and 202 can self-discover and self-organize a network based on the soft bus.

[0331] S911, electronic device 201, and electronic device 203 can discover each other via a soft bus.

[0332] After the soft bus in S912 and electronic device 201 successfully authenticates electronic device 203, electronic device 203 is confirmed to be online.

[0333] After the soft bus in S913 and electronic device 203 successfully authenticates electronic device 201, electronic device 201 is confirmed to be online.

[0334] In some embodiments, the method for device authentication of electronic device 203 via the soft bus in electronic device 201 and the method for device authentication of electronic device 201 via the soft bus in electronic device 203 can both be […]. A device authentication algorithm for achieving secure device interconnection. This application does not limit the specific method of the above-described device authentication in its embodiments.

[0335] S914, electronic device 201 and electronic device 203 can be networked via a soft bus.

[0336] In some embodiments, the soft bus in electronic device 201 and the soft bus in electronic device 203 can also negotiate a session key. This session key can be used by applications in electronic device 201 and electronic device 203 to encrypt data when transmitting data via the soft bus.

[0337] The aforementioned session key can be generated using a 256-bit error correcting code (ECC) algorithm and a HUKS derived algorithm. When negotiating the session key, the soft bus in electronic device 201 and the soft bus in electronic device 203 use an RSA encryption algorithm to encrypt and transmit the negotiated key. This application embodiment does not limit the method for generating the session key or the method for transmitting the session key between devices with the same account.

[0338] S915, Data sharing application 1 receives an operation to share data 2 to electronic device 203.

[0339] The steps for sharing data 2 can be referred to the above. Figure 6A and Figure 6B The operation of sharing data is shown.

[0340] In some embodiments, step S915 is optional. For example, electronic device 201 is a mobile phone. Electronic device 203 is a tablet computer. Electronic device 201 can send the image that the user wants to share to electronic device 203 in response to the user's image sharing operation. Alternatively, electronic device 201 is a smartwatch. Electronic device 203 is a mobile phone. Electronic device 201 can collect data such as heart rate and step count, and automatically send the heart rate, step count, and other data to electronic device 203.

[0341] S916, Data sharing application 1 requests the establishment of session 2 from the soft bus in electronic device 201. Session 2 is used to communicate with data sharing application 3 in electronic device 203.

[0342] S917, electronic device 201, and electronic device 203 establish session 2 via the soft bus.

[0343] If electronic device 201 successfully forms a network and is still in a network, the soft bus in electronic device 201 can establish session 2 with the soft bus in electronic device 203 according to the above request to establish session 2.

[0344] S918, Data sharing application 1 sends data 2 to the soft bus in electronic device 201.

[0345] S919, the soft bus in electronic device 201 sends data 2 to the soft bus in electronic device 203.

[0346] In some embodiments, the soft bus in electronic device 201 may use the session key negotiated with the soft bus in electronic device 203 in step S914 above to encrypt data 2 and send the encrypted data 2 to the soft bus in electronic device 203.

[0347] The soft bus in S920 and electronic device 203 sends data 2 to data sharing application 3.

[0348] The soft bus in electronic device 204 can use the session key obtained by negotiating with the soft bus in electronic device 201 in step S914 above to decrypt the encrypted data 2 and obtain data 2.

[0349] It can be seen that data transmission between electronic devices 201 and 203 depends on the device network, that is, on electronic device 201 confirming that electronic device 203 is online and electronic device 203 confirming that electronic device 201 is online. However, in some embodiments, when electronic devices 201 and 203 need to transmit data, electronic device 201 may detect that electronic device 203 is offline, or electronic device 203 may detect that electronic device 201 is offline. In this case, electronic devices 201 and 203 cannot complete the transmission of service data via the soft bus.

[0350] For example, electronic device 201 can send heartbeat packets to electronic device 203 according to a preset heartbeat cycle based on the soft bus. For example, the duration of the heartbeat cycle can be 5 minutes. This application embodiment does not limit the duration of the aforementioned heartbeat cycle. If electronic device 203 receives a heartbeat packet, it can send a reply message to electronic device 201. Upon receiving the reply message from electronic device 203, electronic device 201 can confirm that electronic device 203 is still online. If electronic device 203 moves away from electronic device 201 before the heartbeat cycle of electronic device 201 has ended, then electronic device 203 is actually offline to electronic device 201. However, electronic device 201 fails to detect the change in the online status of electronic device 203 in a timely manner. At this time, if electronic device 201 needs to send data to electronic device 203, electronic device 201 and electronic device 203 cannot complete the transmission of business data through the soft bus.

[0351] For example, data transmission might fail between two devices with the same account due to synchronization remnants. Synchronization remnants refer to the situation where one electronic device fails to update its perception of the online status of the other. Specifically, if device account 1 is not yet logged into electronic device 201, electronic device 203 may detect electronic device 201 and attempt device authentication, but authentication fails. Therefore, electronic device 203 determines that electronic device 201 is offline. Then, device account 1 logs into electronic device 201, and electronic device 201 successfully authenticates electronic device 203. However, electronic device 203 fails to update the online status of electronic device 201 in a timely manner. Therefore, electronic device 201 can detect that electronic device 203 is online, but electronic device 203 detects that electronic device 201 is offline. When electronic device 201 sends service data to electronic device 203, because electronic device 201 is offline to electronic device 203, electronic device 203 will not receive the service data from electronic device 201. This results in data transmission failure for electronic device 201.

[0352] When only one of the two devices with the same account detects that the other device is online, the two devices with the same account cannot complete the transmission of business data. In this case, if a user tries to share data between these two devices with the same account, the sending device may prompt the user that the sharing has failed. Alternatively, the two devices with the same account can establish a data transmission path based on the method for connecting devices with different accounts as described in the previous embodiment to meet the user's data sharing needs. However, this will cause the user to wait a long time to complete the data sharing, and may also require the user to enter an authentication code for device authentication and click to confirm receipt on the receiving device. In other words, when only one of the two devices with the same account detects that the other device is online, the user's data sharing experience is poor.

[0353] In some embodiments, devices with the same account can store the session key after negotiating it. When data transmission is required between two devices with the same account, and only one device detects the other is online, the devices can look up the historical session key and perform two-way authentication based on it. If authentication is successful, the devices with the same account can achieve encrypted data transmission via the soft bus and the historical session key.

[0354] For example, the session keys negotiated between an electronic device and other devices under the same account can be found in Table 2 below. Table 2 can also be referred to as the same account session key data table.

[0355] Receiver device ID Session key Remaining validity period (days) Device ID3 Session key 5 1 Device ID4 Session key 6 2 Device ID5 Session key 7 2

[0356] Table 2

[0357] Table 2 above is merely an exemplary illustration of the same account session key data table and should not be construed as limiting this application.

[0358] In some embodiments, the validity period of the session key negotiated between an electronic device and a device with the same account may differ from the validity period of the session key negotiated with a device with a different account. For example, the validity period of the session key negotiated between the electronic device and a device with the same account may be 2 days. The validity period of the session key negotiated between the electronic device and a device with a different account may be 7 days. Alternatively, the validity period of the session key negotiated between the electronic device and a device with the same account and the validity period of the session key negotiated between the electronic device and a device with a different account may be the same. This application does not limit the duration of the validity period of the above-mentioned session key.

[0359] As can be seen, in the same account session key data table, there is a one-to-one correspondence between session keys and receiving device IDs. For example, the device ID associated with session key 5 is device ID 3. The device ID associated with session key 6 is device ID 4. The device ID associated with session key 7 is device ID 5. The soft bus in the electronic device storing Table 2 and the soft bus in the electronic device with device ID 3 can encrypt the data to be transmitted between the applications of these two electronic devices based on session key 5.

[0360] Electronic devices can use the receiving device ID to check whether they have stored historical session keys corresponding to communication peer devices with the same account as themselves.

[0361] Beyond the data shown in Table 2, electronic devices may store more or less data when storing session keys negotiated with devices under the same account. For example, electronic devices may also store the public key of the receiving device and information such as the storage time of the session key when storing the session key.

[0362] The following example illustrates how electronic devices 201 and 203 transmit data, with electronic device 201 being the sending device and electronic device 203 being the receiving device. This example demonstrates how devices can connect when only one device in the same account detects that the other device is online.

[0363] Figure 10 An exemplary flowchart of another method for connecting devices with the same account is shown.

[0364] Figure 10 This illustrates a method for device reconnection when the receiving device detects that the sending device is offline within the same account.

[0365] S1011, Data sharing application 1 receives an operation to share data 2 to electronic device 203.

[0366] Step S1011 can be referred to the above. Figure 9The following is an introduction to step S915.

[0367] S1012, Data Sharing Application 1 determines that Electronic Device 203 and Electronic Device 201 are devices with the same account.

[0368] In some embodiments, the data sharing application 1 can obtain the account information of the logged-in account in the electronic device 203 from the soft bus of the electronic device 201, thereby determining whether the electronic device 203 and the electronic device 201 are devices with the same account.

[0369] S1013, Data sharing application 1 requests the establishment of session 2 from the soft bus in electronic device 201. Session 2 is used to communicate with data sharing application 3 in electronic device 203.

[0370] S1014, the soft bus in electronic device 201 sends a negotiation message for establishing session 2 to the soft bus in electronic device 203.

[0371] In some embodiments, the soft bus in electronic device 201 can detect whether electronic device 203 is online. For example, the soft bus in electronic device 201 can detect whether electronic device 203 is in the online device list stored in electronic device 201. When electronic device 203 is detected to be online, the soft bus in electronic device 201 can execute step S1014.

[0372] S1015, the soft bus in electronic device 203 detects whether electronic device 201 is online.

[0373] S1016, the soft bus in electronic device 203 establishes session 2 with the soft bus in electronic device 201, and data sharing application 1 sends data 2 to data sharing application 3 through session 2.

[0374] If the soft bus in electronic device 203 detects that electronic device 201 is online, the soft bus in electronic device 203 can respond to the negotiation message sent by electronic device 201 to establish session 2 and establish session 2 with the soft bus in electronic device 201. Then, data sharing application 1 can send data 2 to data sharing application 3 through the soft bus, as detailed above. Figure 9 The steps S917 to S920 are shown.

[0375] S1017, the soft bus in electronic device 203 obtains the stored session key k3, which is the session key corresponding to electronic device 201.

[0376] In some embodiments, the electronic device 203 stores a session key data table for the same account. This session key data table includes session keys negotiated by the electronic device 203 with devices sharing the same account during data transmissions and which are still valid. The session key data table for the same account can be referenced in Table 2 above.

[0377] If the soft bus in electronic device 203 detects that electronic device 201 is offline, the soft bus in electronic device 203 can query whether the session key corresponding to electronic device 201 is stored based on the device ID of electronic device 201.

[0378] If the session key corresponding to electronic device 201 is not stored, the soft bus in electronic device 203 can send a message to the soft bus in electronic device 201 to indicate that session 2 cannot be established. In some embodiments, upon receiving the message indicating that session 2 cannot be established, electronic device 201 and electronic device 203 can renegotiate the session key and transmit service data according to the following steps a1 to a4:

[0379] Step a1: Electronic devices 201 and 203 establish a device authentication channel. This device authentication channel can be referenced from the aforementioned... Figure 7A The device authentication channel in step S712 shown.

[0380] Step a2: Electronic devices 201 and 203 authenticate each other based on the device authentication channel in step a1, and in accordance with... Figure 7B The method shown negotiates and obtains the session key q1. The device authentication method in this step can be authentication method 1. For example, authentication method 1 can include the CCMP authentication algorithm.

[0381] Step a3: Electronic devices 201 and 203 can re-authenticate each other via the device authentication module through the soft bus. During this re-authentication process, electronic devices 201 and 203 can use the aforementioned session key q1 to ensure the security of the device authentication. The device authentication method in this step can be authentication method 2. For example, authentication method 2 may include... A device authentication algorithm is implemented to ensure secure device interconnection. When electronic device 201 successfully authenticates electronic device 203 using authentication method 2, electronic device 201 can confirm that electronic device 203 is online. When electronic device 203 successfully authenticates electronic device 201 using authentication method 2, electronic device 203 can confirm that electronic device 201 is online. Electronic devices 201 and 203 can negotiate a session key, obtaining session key q2, via a soft bus.

[0382] Step a4: Electronic devices 201 and 203 can complete the data transmission of business applications between them through the soft bus and session key q2.

[0383] Understandably, after electronic devices 201 and 203 execute step a3 above, they can transmit data using the same method as devices with the same account. This eliminates the need for users to click to confirm receipt on the receiving device, simplifying the data sharing process.

[0384] If the session key (e.g., session key k3) corresponding to the electronic device 201 is stored, the soft bus in the electronic device 203 can perform the following step S1018.

[0385] S1018, the soft bus in electronic device 203 uses session key k3 to encrypt the device ID of electronic device 203 and the account ID of device account 1 to obtain encrypted data d3.

[0386] In some embodiments, the soft bus in electronic device 203 can hash and truncate the device ID of electronic device 203 and the account ID of device account 1. The soft bus in electronic device 203 can then use session key k3 to encrypt the hashed and truncated data of the device ID of electronic device 203 and the account ID of device account 1, resulting in encrypted data d3. This reduces data transmission volume and improves the efficiency of two-way authentication between electronic device 201 and electronic device 203 using historical session keys. Alternatively, the soft bus in electronic device 203 can also use the session key to encrypt the complete device ID of electronic device 203 and the complete account ID of device account 1, resulting in encrypted data d3.

[0387] S1019, the soft bus in electronic device 203 sends a response message for establishing session 2 and encrypted data d3 to the soft bus in electronic device 201.

[0388] In some embodiments, the soft bus in electronic device 203 can perform TLV encoding on the encrypted data d3, and then send the TLV-encoded encrypted data d3 to the soft bus in electronic device 201.

[0389] S1020, the soft bus in electronic device 201 obtains the stored session key k4 and successfully decrypts the encrypted data d3 using the session key k4. The session key k4 is the session key corresponding to electronic device 203.

[0390] In some embodiments, electronic device 201 stores a session key data table for the same account. This session key data table includes session keys negotiated by electronic device 201 with other devices sharing the same account during data transmission, and which are still valid. The session key data table can be referenced from Table 2 above. The soft bus in electronic device 201 can query whether a session key corresponding to electronic device 203 is stored based on the device ID of electronic device 203.

[0391] If the session key corresponding to electronic device 203 is not stored, electronic device 201 and electronic device 203 can renegotiate the session key and transmit service data according to steps a1 to a4 above.

[0392] If the session key corresponding to the electronic device 203 (e.g., session key k4) is stored, the electronic device 201 can use the session key k4 to decrypt the encrypted data d3.

[0393] Among them, electronic device 201 can determine whether the data obtained by decrypting encrypted data d3 matches the device ID of electronic device 203 and the account ID of device account 1.

[0394] If the keys do not match, decryption will fail. In the event of decryption failure, electronic devices 201 and 203 can renegotiate the session key and transmit service data according to steps a1 to a4 above.

[0395] If a match is found, decryption is successful. Upon successful decryption, the soft bus in electronic device 201 can execute the following step S1021.

[0396] S1021, the soft bus in electronic device 201 uses session key k4 to encrypt the device ID of electronic device 201 and the account ID of device account 1 to obtain encrypted data d4.

[0397] Step S1021 can be referred to the above. Figure 8 The step S816 shown.

[0398] S1022, the soft bus in electronic device 201 sends a negotiation message for establishing session 2 and encrypted data d4 to the soft bus in electronic device 203.

[0399] In some embodiments, the soft bus in electronic device 201 can perform TLV encoding on the encrypted data d4, and then send the TLV-encoded encrypted data d4 to the soft bus in electronic device 203.

[0400] S1023, the soft bus in electronic device 203 successfully decrypted the encrypted data d4 using session key k3, confirming that electronic device 201 is online.

[0401] Electronic device 203 can determine whether the data obtained by decrypting encrypted data d3 using session key k3 matches the device ID of electronic device 201 and the account ID of device account 1.

[0402] If there is a mismatch, decryption fails. In the event of decryption failure, the soft bus in electronic device 203 can send a message to the soft bus in electronic device 201 to indicate decryption failure. In some embodiments, upon receiving the aforementioned message indicating decryption failure, electronic device 201 and electronic device 203 can renegotiate the session key and transmit service data according to steps a1 to a4 described above.

[0403] If a match is found, decryption is successful. The fact that the electronic device can successfully decrypt encrypted data d4 using session key k3 indicates that session key k3 and session key k4 are the same. That is, the soft bus in electronic device 201 and the soft bus in electronic device 203 can achieve encrypted data transmission based on session key k3 (i.e., session key k4). Upon successful decryption, the soft bus in electronic device 203 can confirm that electronic device 201 is online and further execute the following step S1024 with the soft bus in electronic device 201.

[0404] In some embodiments, not limited to device ID and account ID, the encrypted data d3 and encrypted data d4 can also be generated based on random numbers. Specifically, the soft bus in electronic device 203 can generate random number 3 and encrypt it using session key k3 to generate encrypted data d3. The soft bus in electronic device 203 can send encrypted data d3 to the soft bus in electronic device 201. The soft bus in electronic device 201 can decrypt encrypted data d3 using session key k4 and encrypt the decrypted data using session key k4 to obtain encrypted data d4. Optionally, the soft bus in electronic device 201 can add a preset value (e.g., add 1, or add 2, etc.) to the data obtained by decrypting encrypted data d3 using session key k4, and then encrypt the data with the added preset value using session key k4 to obtain encrypted data d4. The soft bus in electronic device 201 can send encrypted data d4 to the soft bus in electronic device 203. The soft bus in electronic device 203 can decrypt encrypted data d4 using session key k3. The data obtained by the soft bus in electronic device 203 decrypting the encrypted data d4 is the aforementioned random number 3 (or random number 3 plus a preset value), which indicates that the soft bus in electronic device 201 has successfully decrypted the encrypted data d3, and the soft bus in electronic device 203 has successfully decrypted the encrypted data d4. Then, electronic devices 201 and 202 can execute subsequent steps S1024 to S1028.

[0405] It can be seen that the soft bus in electronic device 201 successfully decrypted the encrypted data d3 using session key k4, and the soft bus in electronic device 203 also successfully decrypted the encrypted data d4 using session key k3. This indicates that the two-way authentication between electronic devices 201 and 202 was successful. Therefore, the soft buses in electronic devices 201 and 202 can use session key k3 (i.e., session key k4) to encrypt data, enabling data transmission between data sharing application 1 and data sharing application 3.

[0406] S1024. Session 2 is established between the soft bus in electronic device 201 and the soft bus in electronic device 203.

[0407] S1025, the soft bus in electronic device 201 notifies data sharing application 1 that session 2 has been established.

[0408] The soft bus in electronic device 203 can also notify data sharing application 3 that session 2 has been established.

[0409] S1026, Data sharing application 1 sends data 2 to the soft bus in electronic device 201.

[0410] S1027. The soft bus in electronic device 201 uses session key k4 to encrypt data 2 and then sends it to the soft bus in electronic device 203.

[0411] S1028, the soft bus in electronic device 203 uses session key k3 to decrypt the encrypted data 2 and send it to data sharing application 3.

[0412] As can be seen from the above method, when electronic device 201 needs to send data to electronic device 203, and electronic device 203 detects that electronic device 201 is offline, electronic device 203 can go online after successfully authenticating electronic device 201 using the historical session key. In this way, electronic device 203 can skip using... The device authentication algorithm or other device authentication algorithm that enables secure device interconnection authenticates electronic device 201 and then confirms the online status of electronic device 201, thereby enabling rapid connection between electronic device 201 and electronic device 203 and improving the user experience of sharing data using devices with the same account.

[0413] Furthermore, the session key used to encrypt data during transmission is a session key that electronic devices 201 and 203 have previously negotiated and is still valid. Therefore, the above method can ensure the security of data transmission between electronic devices 201 and 203.

[0414] In some embodiments, the above is performed on electronic device 201. Figure 10After steps S1011 to S1013, the soft bus in electronic device 201 can send an online broadcast to the soft bus in electronic device 203. Upon receiving the online broadcast and detecting that electronic device 203 stores the session key corresponding to electronic device 201 (e.g., session key k3), electronic device 203 can confirm that electronic device 201 is online. Then, electronic devices 201 and 203 can execute... Figure 10 The steps S1024 to S1028 shown are used to complete the transmission of service data.

[0415] Understandably, upon receiving the request to establish session 2 in step S1013, the soft bus in electronic device 201 can detect that electronic device 203 is online. If electronic device 203 is online to electronic device 201, electronic device 201 must store the corresponding session key for electronic device 203. If electronic device 203 can receive the online broadcast from electronic device 201, even if electronic device 201 was previously offline to electronic device 203, electronic device 203 can promptly update the online status of electronic device 201 to online if it stores the corresponding session key. This can significantly improve the speed of non-first-time connections between devices with the same account.

[0416] Figure 11 An exemplary flowchart of another method for connecting devices with the same account is shown.

[0417] Figure 11 This illustrates a method for device reconnection when the sending device detects that the receiving device is offline within the same account.

[0418] S1111, Data sharing application 1 receives an operation to share data 3 to electronic device 203.

[0419] Step S1111 can be referred to the above. Figure 9 The following is an introduction to step S915.

[0420] S1112. Data sharing application 1 determines that electronic device 203 and electronic device 201 are devices with the same account, and detects that electronic device 203 is offline.

[0421] In some embodiments, the data sharing application 1 can obtain the account information of the logged-in account in the electronic device 203 from the soft bus in the electronic device 201, thereby determining whether the electronic device 203 and the electronic device 201 are devices with the same account.

[0422] When it is determined that electronic device 203 and electronic device 201 are devices under the same account, data sharing application 1 can request the soft bus in electronic device 201 to establish a session for communication with data sharing application 3 in electronic device 203. Then, the soft bus in electronic device 201 can detect whether electronic device 203 is online. When electronic device 203 is detected to be offline, the soft bus in electronic device 201 can send a message to data sharing application 1 indicating that electronic device 203 is offline. Based on the message indicating that electronic device 203 is offline, data sharing application 1 can perform the following step S1113.

[0423] S1113, Data Sharing Application 1 and Data Sharing Application 3 establish a device authentication channel.

[0424] The device authentication channel can be referenced as described above. Figure 7A The device authentication channel in step S712 shown.

[0425] S1114. Data sharing application 1 requests to use the session key corresponding to electronic device 203 to encrypt and authenticate data.

[0426] The authentication data may include the device ID of electronic device 201 and the account ID of device account 1. Alternatively, the authentication data may include the hashed and truncated device ID of electronic device 201 and the hashed and truncated account ID of device account 1.

[0427] S1115. The soft bus in electronic device 201 uses session key k4 to encrypt the device ID of electronic device 201 and the account ID of device account 1 to obtain encrypted data d5. Session key k4 is the session key corresponding to electronic device 203.

[0428] The soft bus in electronic device 201 can query whether electronic device 201 stores the session key corresponding to electronic device 203.

[0429] If electronic device 201 does not store the session key corresponding to electronic device 203, electronic device 201 and electronic device 203 can proceed as described above. Figure 10 Steps a2 to a4 are shown to renegotiate the session key and transmit service data. The device authentication channel used in step a2 can be the same as the device authentication channel in step S1113 mentioned above.

[0430] If electronic device 201 stores the session key (e.g., session key k4) corresponding to electronic device 203, the soft bus in electronic device 201 can use session key k4 to encrypt the device ID of electronic device 201 and the account ID of device account 1 to obtain encrypted data d5. See the foregoing for details. Figure 10 The step S1020 shown.

[0431] S1116, The soft bus in electronic device 201 sends encrypted data d5 to data sharing application 1.

[0432] S1117, Data sharing application 1 sends encrypted data d5 to data sharing application 3.

[0433] The encrypted data d5 can be transmitted through the device authentication channel established in step S1113 above.

[0434] S1118, Data sharing application 3 requests the soft bus in electronic device 203 to decrypt encrypted data d5.

[0435] S1119, the soft bus in electronic device 203 obtains the stored session key k3 and successfully decrypts the encrypted data d5 using the session key k3. The session key k3 is the session key corresponding to electronic device 201.

[0436] The soft bus in electronic device 203 can query whether electronic device 203 stores the session key corresponding to electronic device 201.

[0437] If electronic device 203 does not store the session key corresponding to electronic device 201, the soft bus in electronic device 203 can send a message to the soft bus in electronic device 201 to indicate that decryption of encrypted data d5 has failed. Based on the message indicating that decryption of encrypted data d5 has failed, electronic devices 201 and 203 can proceed as described above. Figure 10 Steps a2 to a4 are shown to renegotiate the session key and transmit service data. The device authentication channel used in step a2 can be the same as the device authentication channel in step S1113 mentioned above.

[0438] If electronic device 203 stores the session key (e.g., session key k3) corresponding to electronic device 201, the soft bus in electronic device 203 can use session key k3 to decrypt encrypted data d5.

[0439] The soft bus in electronic device 203 can determine whether the data obtained by decrypting encrypted data d5 using session key k3 matches the device ID of electronic device 201 and the account ID of device account 1.

[0440] If there is a mismatch, decryption of the encrypted data d5 fails. The soft bus in electronic device 203 can send a message to the soft bus in electronic device 201 to indicate that decryption of the encrypted data d5 has failed. Based on the message indicating that decryption of the encrypted data d5 has failed, electronic devices 201 and 203 can proceed as described above. Figure 10Steps a2 to a4 are shown to renegotiate the session key and transmit service data. The device authentication channel used in step a2 can be the same as the device authentication channel in step S1113 mentioned above.

[0441] If a match is found, the encrypted data d5 is successfully decrypted, and the soft bus in electronic device 203 can execute the following steps S1120.

[0442] S1120, the soft bus in electronic device 203 uses session key k3 to encrypt the device ID of electronic device 203 and the account ID of device account 1 to obtain encrypted data d6.

[0443] If electronic device 203 successfully decrypts encrypted data d5 using session key k3, then the soft bus in electronic device 203 can use session key k3 to encrypt the device ID of electronic device 203 and the account ID of device account 1, obtaining encrypted data d6. See the preceding text for details. Figure 10 The step S1018 shown.

[0444] S1121, the soft bus in electronic device 203 sends encrypted data d6 to data sharing application 3.

[0445] S1122, Data sharing application 3 sends encrypted data d6 to data sharing application 1.

[0446] Encrypted data d6 can be transmitted through the device authentication channel established in step S1113 above.

[0447] S1123, Data sharing application 1 requests the soft bus in electronic device 201 to decrypt encrypted data d6.

[0448] S1124, The soft bus in electronic device 201 successfully decrypted the encrypted data d6 using session key k4.

[0449] The soft bus in electronic device 201 can determine whether the data obtained by decrypting encrypted data d5 using session key k4 matches the device ID and account ID of the device account in electronic device 203.

[0450] If there is a mismatch, decryption of the encrypted data d6 will fail, and electronic devices 201 and 203 can proceed as described above. Figure 10 Steps a2 to a4 are shown to renegotiate the session key and transmit service data. The device authentication channel used in step a2 can be the same as the device authentication channel in step S1113 mentioned above.

[0451] If a match is found, the encrypted data d6 is successfully decrypted, and the soft bus in electronic device 201 can execute the following step S1125.

[0452] S1125, The soft bus in electronic device 201 confirms that electronic device 203 is online.

[0453] If the soft bus in electronic device 201 successfully decrypts the encrypted data d6 using session key k4, then the soft bus in electronic device 201 can confirm that electronic device 203 is online. Successful decryption of encrypted data d6 using session key k4 indicates that session key k3 and session key k4 are the same.

[0454] In some embodiments, not limited to device ID and account ID, the encrypted data d5 and encrypted data d6 can also be generated based on random numbers. Specifically, the soft bus in electronic device 201 can generate random number 4 and encrypt it using session key k4 to generate encrypted data d5. Data sharing application 1 can send encrypted data d5 to data sharing application 3. The soft bus in electronic device 203 can decrypt encrypted data d5 using session key k3 and encrypt the decrypted data using session key k3 to obtain encrypted data d6. Optionally, the soft bus in electronic device 203 can add a preset value (e.g., add 1, or add 2, etc.) to the data obtained by decrypting encrypted data d5 using session key k3, and then encrypt the data with the added preset value using session key k3 to obtain encrypted data d6. Data sharing application 3 can send encrypted data d6 to data sharing application 1. The soft bus in electronic device 201 can decrypt encrypted data d6 using session key k4. The data obtained by the soft bus in electronic device 201 decrypting the encrypted data d6 is the aforementioned random number 4 (or random number 4 plus a preset value), which indicates that the soft bus in electronic device 203 successfully decrypted the aforementioned encrypted data d5, and the soft bus in electronic device 201 successfully decrypted the aforementioned encrypted data d6.

[0455] It can be seen that the soft bus in electronic device 201 successfully decrypted the encrypted data d6 using session key k4, and the soft bus in electronic device 203 successfully decrypted the encrypted data d5 using session key k3, which indicates that the two-way authentication between electronic device 201 and electronic device 202 was successful.

[0456] Therefore, after confirming that electronic device 201 is online, the soft bus in electronic device 201 can establish a session with the soft bus in electronic device 203, and use session key k3 (i.e., session key k4) for data encryption, thereby enabling data transmission between data sharing application 1 and data sharing application 3. For details, please refer to the aforementioned... Figure 10 The steps S1024 to S1028 are shown.

[0457] As can be seen from the above method, when electronic device 201 needs to send data to electronic device 203, and electronic device 201 detects that electronic device 203 is offline, electronic device 201 can go online after successfully authenticating with electronic device 203 using the historical session key. In this way, electronic device 201 can skip using... The device authentication algorithm or other device authentication algorithm that enables secure device interconnection performs device authentication on electronic device 203, and then confirms the online status of electronic device 203, thereby enabling rapid connection between electronic device 201 and electronic device 203, and thus improving the user experience of sharing data with devices using the same account.

[0458] Furthermore, the session key used to encrypt data during transmission is a session key that electronic devices 201 and 203 have previously negotiated and is still valid. Therefore, the above method can ensure the security of data transmission between electronic devices 201 and 203.

[0459] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the above-described method embodiments.

[0460] This application also provides a computer program product, including a computer program that, when run on a processor, can implement the steps in the various method embodiments described above.

[0461] This application also provides a chip system, which includes a processing circuit and an interface circuit. The interface circuit receives code instructions and transmits them to the processing circuit. The processing circuit executes the code instructions to enable the chip system to implement the steps of any method embodiment of this application. The chip system can be a single chip or a chip module composed of multiple chips.

[0462] It is understood that the user interfaces described in the embodiments of this application are merely example interfaces and do not constitute a limitation on the solution of this application. In other embodiments, the user interface may adopt different interface layouts, may include more or fewer controls, and may add or remove other functional options, as long as they are based on the same inventive concept provided in this application, they are all within the protection scope of this application.

[0463] It should be noted that, without causing contradictions or conflicts, any feature in any embodiment of this application, or any part of any feature, can be combined, and the combined technical solution is also within the scope of the embodiments of this application.

[0464] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A device connection method, characterized in that, The method is applied to a communication system including a first device and a second device, and the method includes: The first device queries the memory of the second device for the session key corresponding to the second device; If the first session key corresponding to the second device is found, the first device uses the first session key to encrypt the first authentication data, generates the first encrypted data, and sends the first encrypted data to the second device. The second device queries the session key corresponding to the first device in the memory of the second device; If the second session key corresponding to the first device is found, the second device uses the second session key to decrypt the first encrypted data. If the first encrypted data is successfully decrypted, the second device uses the second session key to encrypt the second authentication data, generates the second encrypted data, and sends the second encrypted data to the first device. If the first device successfully decrypts the second encrypted data using the first session key, the first device and the second device establish a first session, which is used for applications in the first device and applications in the second device to transmit data.

2. The method according to claim 1, characterized in that, Before the first device queries the session key corresponding to the second device in the memory of the first device, the method further includes: The first device receives an operation to send first data to the second device; After the first device and the second device establish a first session, the method further includes: The first device uses the first session key to encrypt the first data, generates third encrypted data, and sends the third encrypted data to the second device.

3. The method according to claim 1 or 2, characterized in that, The first device is logged into a first device account, the second device is logged into a second device account, the first device contains a first application, the second device contains a second application, and the first session is used for the first application and the second application to transmit data; The query for the first session key corresponding to the second device specifically includes: The first device retrieves the first session key based on the device ID of the second device, the account ID of the second device account, the identifier of the first application, and the identifier of the second application; The process of retrieving the second session key corresponding to the first device specifically includes: The second device retrieves the second session key based on the device ID of the first device, the account ID of the first device account, the identifier of the first application, and the identifier of the second application.

4. The method according to claim 3, characterized in that, The first authentication data is determined based on the device ID of the first device and the account ID of the first device account, and the second authentication data is determined based on the device ID of the second device and the account ID of the second device account; or, the first authentication data includes a first random number, and the second authentication data includes data obtained by decrypting the first encrypted data using the second session key.

5. The method according to claim 3 or 4, characterized in that, The method further includes: When the second device logs out of the second device account, the first device deletes the session key corresponding to the second device, and the second device deletes the session key corresponding to the first device.

6. The method according to claim 1 or 2, characterized in that, The first device has a first device account logged in, the second device has no device account logged in, the first device contains a first application, the second device contains a second application, and the first session is used for the first application and the second application to transmit data; The query for the first session key corresponding to the second device specifically includes: The first device retrieves the first session key based on the device ID of the second device, the identifier of the first application, and the identifier of the second application; The process of retrieving the second session key corresponding to the first device specifically includes: The second device retrieves the second session key based on the device ID of the first device, the account ID of the first device account, the identifier of the first application, and the identifier of the second application.

7. The method according to any one of claims 3-6, characterized in that, The method further includes: If the first device fails to find the first session key, or the second device fails to find the second session key, or the second device fails to decrypt the first authentication data using the second session key, or the first device fails to decrypt the second authentication data using the first session key, then the first device and the second device use the first device authentication algorithm to perform device authentication and negotiate to obtain the third session key to establish the first session; The first device and the second device store the third session key.

8. The method according to claim 2, characterized in that, Both the first device and the second device are logged into with the first device account; before the first device queries the session key corresponding to the second device in the first device's memory, the method further includes: The first device detects that the second device is offline, and the second device detects that the first device is online.

9. The method according to claim 1, characterized in that, Both the first device and the second device are logged into with a first device account. Before the first device queries the session key corresponding to the second device in the first device's memory, the method further includes: The second device receives an operation to send second data to the first device, detects that the first device is online, and sends a message to the first device to establish the first session; The first device detected that the second device was offline; After the first device and the second device establish a first session, the method further includes: The second device uses the second session key to encrypt the second data, generates fourth encrypted data, and sends the fourth encrypted data to the first device.

10. The method according to claim 8 or 9, characterized in that, The query for the first session key corresponding to the second device specifically includes: The first device retrieves the first session key based on the device ID of the second device; The process of retrieving the second session key corresponding to the first device specifically includes: The second device retrieves the second session key based on the device ID of the first device.

11. The method according to any one of claims 8-10, characterized in that, The method further includes: If the first device fails to find the first session key, or the second device fails to find the second session key, or the second device fails to decrypt the first authentication data using the second session key, or the first device fails to decrypt the second authentication data using the first session key, then the first device and the second device use the first device authentication algorithm to perform device authentication and negotiate to obtain a fourth session key. The first device and the second device use a fourth session key and a second device authentication algorithm to authenticate each other and negotiate a fifth session key to establish the first session; The first device and the second device store the fifth session key.

12. The method according to any one of claims 1-11, characterized in that, The method further includes: When the storage time for the first session key is detected to have expired, the first device deletes the first session key. When the storage time for the second session key is detected to have expired, the second device deletes the second session key.

13. A device connection method, characterized in that, The method includes: The first device queries the session key corresponding to the second device in the memory of the first device; If the first session key corresponding to the second device is found, the first device uses the first session key to encrypt the first authentication data, generates the first encrypted data, and sends the first encrypted data to the second device. The first device receives second encrypted data from the second device; If the first device successfully decrypts the second encrypted data using the first session key, the first device and the second device establish a first session, which is used for applications in the first device and applications in the second device to transmit data.

14. The method according to claim 13, characterized in that, Before the first device queries the session key corresponding to the second device in the memory of the first device, the method further includes: The first device receives an operation to send first data to the second device; After the first device and the second device establish a first session, the method further includes: The first device uses the first session key to encrypt the first data, generates third encrypted data, and sends the third encrypted data to the second device.

15. The method according to claim 13 or 14, characterized in that, The first device is logged into a first device account, the first device contains a first application, and the first session is used for data transmission between the first application and a second application in the second device; The query for the first session key corresponding to the second device specifically includes: The first device retrieves the first session key based on the device ID of the second device, the account ID of the second device account logged in on the second device, the identifier of the first application, and the identifier of the second application.

16. The method according to claim 15, characterized in that, The first authentication data is determined based on the device ID of the first device and the account ID of the first device account; or, the first authentication data includes a first random number.

17. The method according to claim 15 or 16, characterized in that, The method further includes: When the device account logged in on the second device is detected to have switched from the second device account to the third device account, the first device deletes the session key corresponding to the second device.

18. The method according to any one of claims 15-17, characterized in that, The method further includes: If the first device fails to find the first session key, or if the first device fails to decrypt the second authentication data using the first session key, then the first device uses the first device authentication algorithm to authenticate the second device and negotiates with the second device to obtain the third session key, and establishes the first session. The first device stores the third session key.

19. The method according to claim 14, characterized in that, Before the first device queries the session key corresponding to the second device from its memory, the method further includes: (The first device is logged into with a first device account.) The first device confirms that the account logged in on the second device is the same as the account on the first device; The first device detected that the second device was offline.

20. The method according to claim 13, characterized in that, Before the first device queries the session key corresponding to the second device from its memory, the method further includes: (The first device is logged into with a first device account.) The first device receives a message from the second device for establishing the first session; The first device detected that the second device was offline; After the first device and the second device establish a first session, the method further includes: The first device receives fourth encrypted data from the second device and decrypts the fourth encrypted data using the first session key.

21. The method according to claim 19 or 20, characterized in that, The query for the first session key corresponding to the second device specifically includes: The first device retrieves the first session key based on the device ID of the second device.

22. The method according to any one of claims 13-21, characterized in that, The method further includes: When the storage time for the first session key is detected to have expired, the first device deletes the first session key.

23. A device connection method, characterized in that, The method includes: The second device receives the first encrypted data from the first device; The second device queries the session key corresponding to the first device in the memory of the second device; If the second session key corresponding to the first device is found, the second device uses the second session key to decrypt the first encrypted data. If the first encrypted data is successfully decrypted, the second device uses the second session key to encrypt the second authentication data, generates the second encrypted data, and sends the second encrypted data to the first device. The second device and the first device establish a first session, which is used for applications in the first device and applications in the second device to transmit data.

24. The method according to claim 23, characterized in that, The second device may or may not have a device account logged in. The second device contains a second application. The first session is used for data transmission between the second application and the first application in the first device. The process of retrieving the second session key corresponding to the first device specifically includes: The second device retrieves the second session key based on the device ID of the first device, the account ID of the first device account logged in on the first device, the identifier of the first application, and the identifier of the second application.

25. The method according to claim 24, characterized in that, The second authentication data is determined based on the device ID of the second device and the account ID of the second device account; or, the second authentication data is determined based on the device ID of the second device; or, the second authentication data includes data obtained by decrypting the first encrypted data using the second session key.

26. The method according to claim 24 or 25, characterized in that, The device account logged in on the second device is switched from the second device account to the third device account; the method further includes: The second device deletes the session key corresponding to the first device.

27. The method according to claim 23, characterized in that, The method further includes: If the second device fails to find the second session key, or if the second device fails to decrypt the first authentication data using the second session key, the second device uses the first device authentication algorithm to authenticate the first device and negotiates with the first device to obtain the third session key, and establishes the first session. The second device stores the third session key.

28. The method according to any one of claims 23-27, characterized in that, After the second device and the first device establish a first session, the method further includes: The second device receives third encrypted data from the first device and decrypts the third encrypted data using the second session key.

29. The method according to claim 23, characterized in that, Before the second device receives the first encrypted data from the first device, the method further includes: (The second device is logged into the first device account.) The second device receives an operation to send second data to the first device, detects that the first device is online, and sends a message to the first device to establish a first session; After the second device and the first device establish a first session, the method further includes: The second device uses the second session key to encrypt the second data, generates fourth encrypted data, and sends the fourth encrypted data to the first device.

30. The method according to claim 29, characterized in that, The process of retrieving the second session key corresponding to the first device specifically includes: The second device retrieves the second session key based on the device ID of the first device.

31. The method according to any one of claims 23-30, characterized in that, The method further includes: When the storage time for the second session key is detected to have expired, the second device deletes the second session key.

32. An electronic device, characterized in that, The electronic device includes a memory and a processor, wherein the memory is used to store a computer program; the processor executes the computer program to implement the method of any one of claims 13-31.

33. A computationally readable storage medium storing instructions, characterized in that, When the instructions are executed by the processor, they implement the method of any one of claims 13-31.

34. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the method of any one of claims 13-31.

Images