Communication method and apparatus, electronic device, and computer-readable storage medium

Abstract

This application discloses a communication method, apparatus, electronic device, and computer-readable storage medium, belonging to the field of communication technology. The method includes: upon detecting an anomaly in a first connection between a second device and a first communication protocol, performing parameter coordination with the second device through a secure channel established by a second connection based on a second communication protocol to obtain coordination parameters; generating a second key based on the coordination parameters and a first key corresponding to the second connection; and resuming data communication with the second device based on the second key and the first communication protocol. Thus, when the first connection is abnormal, a second key can be automatically derived through the secure channel of the established second connection, allowing for automatic communication recovery without user intervention, thereby significantly improving the device's connection reliability, recovery efficiency, and user experience.

Description

Technical Field

[0001] This application relates to the field of display technology, specifically to a communication method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] Current smart devices typically support multiple communication protocols. However, when one of these protocols is abnormally interrupted due to non-human factors such as signal interference, physical obstruction, or connection timeout, the user usually needs to manually re-establish the connection process for that protocol. Manual connection is cumbersome and can negatively impact the user experience. Summary of the Invention

[0003] This application provides a communication method, apparatus, electronic device, and computer-readable storage medium that can automatically restore communication by means of a secure connection based on a second communication protocol when the connection of a first communication protocol is abnormal, thereby significantly improving the connection reliability, recovery efficiency, and user experience of the device.

[0004] In a first aspect, embodiments of this application provide a communication method applied to a first device, comprising: When an anomaly is detected in the first connection between the first communication protocol and the second device, the parameters are coordinated with the second device through a secure channel established by the second connection between the second communication protocol and the second device to obtain the coordination parameters. A second key is generated based on the collaboration parameters and the first key corresponding to the second connection; Based on the second key, data communication with the second device based on the first communication protocol is resumed.

[0005] In one embodiment, the first communication protocol is Bluetooth Low Energy, the second communication protocol is Bluetooth Classic, and the first key is a connection key generated based on pairing using the Bluetooth Classic protocol.

[0006] In one embodiment, the collaboration parameters include at least one of a device address identifier, a session random number, and a privacy parameter; the device address identifier includes a first address identifier of the first device and a second address identifier of the second device.

[0007] In one embodiment, the second key includes at least one of a first subkey and a second subkey, wherein the first subkey is used for encryption of the first communication protocol link and the second subkey is used for device privacy protection; The step of generating a second key based on the collaboration parameters and the first key corresponding to the second connection includes: The first key, the device address identifier, and the session random number are encrypted to obtain the first subkey; and / or, The first subkey is obtained by performing encryption operations on the first key, the device address identifier, and the privacy parameters.

[0008] In one embodiment, after generating the second key based on the collaboration parameters and the first key corresponding to the second connection, the method further includes: The second device exchanges verification information for the second key through the secure channel; When it is determined that the second keys of the first device and the second device are consistent based on the verification information, the second key is stored in the local secure storage area.

[0009] In one embodiment, the verification information of the second key is generated in the following manner: Based on the first address identifier of the first device and the second address identifier of the second device, target confirmation information is generated; The second key and the target confirmation information are hashed to obtain the verification information.

[0010] In one embodiment, the step of resuming data communication with the second device based on the first communication protocol, using the second key, includes: The target data is encrypted using the second key to obtain an encrypted data packet; The encrypted data packet is sent through the broadcast channel of the first communication protocol, so that when the second device listens to the encrypted data packet, it can decrypt the encrypted data packet based on the second key that the second device has synchronized, and obtain the target data.

[0011] Secondly, embodiments of this application provide a communication device used in a first device, the device comprising: The parameter coordination module is used to coordinate parameters with the second device through a secure channel established by the second connection based on the second communication protocol when a first connection anomaly between the second device and the first communication protocol is detected, so as to obtain coordinated parameters. A key generation module is used to generate a second key based on the collaboration parameters and the first key corresponding to the second connection; The communication recovery module is used to restore data communication with the second device based on the first communication protocol, using the second key.

[0012] In one embodiment, the first communication protocol is Bluetooth Low Energy, the second communication protocol is Bluetooth Classic, and the first key is a connection key generated based on pairing using the Bluetooth Classic protocol.

[0013] In one embodiment, the collaboration parameters include at least one of a device address identifier, a session random number, and a privacy parameter; the device address identifier includes a first address identifier of the first device and a second address identifier of the second device.

[0014] In one embodiment, the second key includes at least one of a first subkey and a second subkey, wherein the first subkey is used for encryption of the first communication protocol link, and the second subkey is used for device privacy protection; the key generation module includes: The first generation submodule is used to perform encryption operations on the first key, the device address identifier and the session random number to obtain the first subkey; The second generation submodule is used to perform encryption operations on the first key, the device address identifier, and the privacy parameters to obtain the first subkey.

[0015] In one embodiment, the communication device further includes: The information exchange module is used to exchange verification information for the second key with the second device through the secure channel; The key storage module is used to store the second key in a local secure storage area when it is determined from the verification information that the second keys of the first device and the second device are consistent.

[0016] In one embodiment, the verification information of the second key is generated in the following manner: Based on the first address identifier of the first device and the second address identifier of the second device, target confirmation information is generated; The second key and the target confirmation information are hashed to obtain the verification information.

[0017] In one embodiment, the communication recovery module includes: The encryption submodule is used to encrypt the target data using the second key to obtain an encrypted data packet; The data transmission submodule is used to send the encrypted data packet through the broadcast channel of the first communication protocol, so that when the second device listens to the encrypted data packet, it can decrypt the encrypted data packet based on the second key that the second device has synchronized to obtain the target data.

[0018] Thirdly, embodiments of this application also provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps in the communication method described above.

[0019] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the above-described communication method.

[0020] Fifthly, embodiments of this application also provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations described in the embodiments of this application.

[0021] In summary, in this embodiment, when an anomaly is detected in the first connection between the device and the second device based on the first communication protocol, parameter coordination with the second device is performed through a secure channel established by the second connection based on the second communication protocol to obtain coordination parameters. A second key is generated based on the coordination parameters and the first key corresponding to the second connection. Data communication with the second device based on the first communication protocol is then restored using the second key. Thus, when the first connection is abnormal, the second key can be automatically derived through the established secure channel of the second connection, allowing for automatic communication restoration without user intervention, thereby significantly improving the device's connection reliability, recovery efficiency, and user experience. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a schematic flowchart of a communication method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the interaction process between the first device and the second device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0024] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0025] It should be noted that current smart devices typically support multiple communication protocols. For example, dual-mode Bluetooth devices can simultaneously support BR / EDR (Basic Rate / Enhanced Data Rate, commonly known as Classic Bluetooth) and BLE (Bluetooth Low Energy) protocols. When a BLE connection is abnormally interrupted due to signal interference, physical obstruction, or pairing timeout, it usually needs to restart the entire BLE pairing process, regenerating and redistributing the key. Although devices may have established a stable pairing relationship through the BR / EDR protocol and hold a Link Key, current technology lacks an effective mechanism to quickly restore BLE communication using this existing security foundation when a BLE connection fails.

[0026] Traditional CTKD (Cross-Transport Key Derivation) technology is mainly used to achieve cross-protocol key synchronization during the initial device binding phase. However, during connection maintenance and anomaly recovery phases, especially after BLE connection timeouts or interruptions, it cannot dynamically derive and synchronize the required BLE keys based on the established trust relationship and secure channel of BR / EDR, thus failing to achieve seamless and automatic link recovery. This forces users to repeatedly perform pairing operations after BLE connection anomalies, which is not only cumbersome and time-consuming but also reduces the consistency and reliability of device use.

[0027] To address the current issue of devices failing to self-heal after connection anomalies, this application aims to provide a communication method. When a first connection anomaly is detected between a device and a second device based on a first communication protocol, a secure channel is established through a second connection based on a second communication protocol. This channel facilitates parameter coordination with the second device to obtain coordination parameters. Based on the coordination parameters and a first key corresponding to the second connection, a second key is generated. This second key enables the resumption of data communication with the second device based on the first communication protocol. Thus, when a first connection anomaly occurs, a second key is automatically derived through the established secure channel of the second connection, allowing for automatic communication recovery without user intervention. This significantly improves device connection reliability, recovery efficiency, and user experience.

[0028] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the priority of the embodiments.

[0029] Figure 1 The illustration shows a schematic flowchart of a communication method according to an embodiment of this application. The entity executing the communication method can be a communication device, which can be integrated into any electronic device with data processing, network communication, and program execution functions. The electronic device can be a server or a terminal, etc.

[0030] The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, network acceleration services (Content Delivery Network, CDN), as well as big data and artificial intelligence platforms.

[0031] The terminal can be a smartphone, tablet, laptop, desktop computer, smart home device, wearable device, etc., but is not limited to these. The terminal and the server can be connected directly or indirectly through wired or wireless communication, which is not limited herein.

[0032] In this embodiment, the description will be from the perspective of a communication device, which can be integrated into a server or terminal. To facilitate the explanation of the communication method of this application, the following will describe the communication device integrated into a first device in detail, that is, the first device will be used as the execution subject for detailed explanation.

[0033] Reference Figure 1 The diagram shows a flowchart of a communication method according to this application. The method may specifically include steps S101 to S103, as follows: S101: When an anomaly is detected in the first connection between the first communication protocol and the second device, parameter coordination is performed with the second device through the secure channel established by the second connection between the second communication protocol and the second device to obtain coordination parameters.

[0034] In this embodiment, when the first device initiates or maintains a first connection with the second device based on the first communication protocol, it will obtain the monitoring index information of the first device, and when it detects that the monitoring index information meets the preset abnormal conditions, it will determine that the first connection between the first device and the second device based on the first communication protocol is abnormal.

[0035] In this implementation, monitoring indicators may include: whether the connection request timed out, whether the link layer confirmation failed consecutively, whether the received signal strength was lower than the strength threshold, or whether the protocol stack returned a connection error. When any monitoring indicator meets the corresponding abnormal condition, the first connection is determined to be abnormal, and the subsequent recovery process is automatically triggered without user intervention.

[0036] In this embodiment, the first communication protocol and the second communication protocol refer to two different wireless or wired communication protocols supported between the first device and the second device. The second communication protocol has successfully established a stable and secure connection, and in the process, a first key for authentication and encryption between the two parties has been generated. When the first connection based on the first communication protocol fails, the second connection established using the second communication protocol will be used as a security basis to restore the first connection.

[0037] In this embodiment, a secure channel refers to a data transmission path constructed based on a second connection using a second communication protocol, capable of encryption and integrity protection. This secure channel utilizes a first key negotiated during the establishment of the second connection to protect the transmitted content, ensuring that the parameter coordination process is not eavesdropped on or tampered with.

[0038] In this embodiment, the coordination parameters refer to a set of data that the first device and the second device need to jointly determine to generate the second key during the first connection failure recovery process. The coordination parameters may include information used to ensure the uniqueness and freshness of the key.

[0039] In this embodiment, after triggering recovery, the first device can immediately send a recovery request to the second device through an existing, secure second connection. Both parties exchange and negotiate the coordination parameters required to generate the second key through this secure channel. For example, the coordination parameters may include device address identifiers of both devices and / or at least one random number generated by one party and confirmed by the other.

[0040] S102: Generate a second key based on the coordination parameters and the first key corresponding to the second connection.

[0041] In this embodiment, the first key is an encryption key generated based on the pairing or handshake process of the second communication protocol, which is a manifestation of the trust relationship between the two parties; the second key is a new encryption key derived from the first key and the cooperation parameters, which is used to restore or rebuild the encrypted communication link of the first communication protocol.

[0042] In this embodiment, both the first device and the second device will use the same first key and agreed-upon collaboration parameters as inputs to perform calculations and independently derive the same second key.

[0043] S103: Resume data communication with the second device based on the first communication protocol, using the second key.

[0044] In this embodiment, after generating the second key, the first device can use the second key to encrypt the target data to be sent to the second device, and then send it out through the communication method defined by the first communication protocol. The second device uses the synchronized second key to decrypt the data, thereby restoring the data interaction at the application layer.

[0045] In this embodiment, when an anomaly in the first communication protocol connection is detected, parameter coordination is intelligently performed using the secure channel established through the second communication protocol, and a second key is locally derived based on the existing first key, ultimately achieving rapid and automatic recovery of data communication via the first communication protocol. This avoids the drawbacks of traditional solutions that require users to manually reconnect or re-execute the entire key negotiation process, significantly improving the device's connection reliability, recovery speed, and user experience in complex wireless environments.

[0046] In one feasible implementation, the first communication protocol can be Bluetooth Low Energy protocol, the second communication protocol can be Bluetooth Classic protocol, and the first key can be a connection key generated based on pairing using Bluetooth Classic protocol.

[0047] It's important to note that Bluetooth Low Energy (BLE) is a communication protocol that follows the Bluetooth Low Energy technology standard defined in the Bluetooth Core Specification. Its characteristics include design for extremely low power consumption and intermittent data communication, employing connect-and-broadcast modes, and it is widely used in IoT devices and wearable devices. Bluetooth Classic, on the other hand, refers to a communication protocol that follows the Basic Rate / Enhanced Data Rate (BRDR) technology standard defined in the Bluetooth Core Specification. Its characteristics include support for higher data throughput and continuous data streaming, and it is widely used in audio streaming, file transfer, and other scenarios. A connection key is a long-term key that is jointly negotiated and securely exchanged by the first and second devices during the Bluetooth Classic pairing process using a pairing algorithm. This connection key, often called the Link Key, is stored locally on the device and used for authentication and link encryption in subsequent Bluetooth Classic connections. It serves as the cryptographic credential for establishing a trust relationship between the two parties.

[0048] In this embodiment, the first device and the second device can be devices that support dual-mode Bluetooth. If the BLE connection between the first device and the second device is interrupted, the BLE connection can be automatically restored using the existing BR / EDR connection.

[0049] In this embodiment, for devices that support multi-protocol communication, the first and second communication protocols can be other communication protocols in different communication scenarios.

[0050] For example, in an IoT scenario, the first communication protocol can be Zigbee, and the second communication protocol can be Wi-Fi (mobile hotspot) or Ethernet that the first device is connected to. When the link of the Zigbee-based Mesh network is unstable, secure coordination can be performed through the IP network.

[0051] For example, in a mobile communication and local area network (LAN) collaboration scenario, the first communication protocol can be Wi-Fi, and the second communication protocol can be cellular mobile network. In the event of a Wi-Fi connection failure, the device's 4G / 5G data channel securely synchronizes parameters to quickly rebuild a secure Wi-Fi direct connection or re-access the LAN.

[0052] For example, in a wired and wireless co-operation scenario, the first communication protocol can be a wireless protocol, and the second communication protocol can be a USB or Ethernet wired connection. When the wireless connection is unstable, the key of the unstable wireless link can be recovered through a reliable wired channel.

[0053] In one feasible implementation, the coordination parameters include at least one of device address identifier, session random number and privacy parameters; the device address identifier includes a first address identifier of a first device and a second address identifier of a second device.

[0054] In this embodiment, the device address identifier refers to the address that uniquely identifies a network interface or device in network communication. The first address identifier is the unique hardware address of the first device, and the second address identifier is the unique hardware address of the second device. For example, the first address identifier can be the MAC (Media Access Control Address) of the first device, or the BD_ADDR (Bluetooth Device Address) of the BR / EDR, or the Identity Address of the BLE; the second address identifier can be the MAC, or the BD_ADDR of the BR / EDR, or the Identity Address of the BLE.

[0055] In this implementation, the session random number refers to a one-time random value generated or used in a single recovery session. Its core characteristics are unpredictability and uniqueness, which are used to ensure that the final generated key is different each time the recovery process is executed, even if other inputs are the same, thereby providing freshness and preventing replay attacks.

[0056] In this embodiment, privacy parameters refer to additional parameters used to enhance the privacy protection features of the second key or to meet specific application requirements. Their specific content can be customized according to security needs. For example, privacy parameters may include identity resolution-related parameters, application-specific identifiers, and algorithm-supplemented salt values. Identity resolution-related parameters may include seed information used to generate the BLE identity resolution key; application-specific identifiers may include user ID, device role code, etc. Algorithm-supplemented salt values ​​can be used to increase the randomness and complexity of the key derivation process.

[0057] In this embodiment, the device address identifiers of both communicating parties are used as input, making the generated second key strongly associated with the two specific devices. This prevents the second key from being used by any third-party device, even if they somehow obtain the same derivation algorithm and other parameters, they will not be able to calculate the correct session key. By introducing session random numbers, uniqueness and replay attack prevention are enhanced, ensuring that a completely new second key is generated each time communication is resumed, making past encrypted data undecryptable and guaranteeing the independence of each session. Privacy parameters provide a way to customize and enhance security. For example, when it is necessary to derive a BLE IRK, the privacy parameters can contain specific information required to generate the IRK (Identity Resolving Key). By flexibly defining privacy parameters, the special requirements of different protocols or applications for key attributes can be adapted, thereby expanding the functionality of the solution.

[0058] In one feasible implementation, the second key includes at least one of a first subkey and a second subkey, wherein the first subkey is used for encryption of the first communication protocol link, and the second subkey is used for device privacy protection. The step of generating the second key based on the coordination parameters and the first key corresponding to the second connection may include: performing an encryption operation on the first key, the device address identifier, and a session random number to obtain the first subkey; and / or, performing an encryption operation on the first key, the device address identifier, and the privacy parameters to obtain the first subkey.

[0059] In this embodiment, the second key derived from the first subkey is a key component specifically used for encrypting and decrypting the data link established by the first communication protocol. Its function is to ensure the confidentiality of transmitted data and prevent eavesdropping on data at the wireless air interface. For example, in the Bluetooth Low Energy protocol, the first subkey is an LTK (Long Term Key), used to generate a session encryption key and encrypt data packets at the link layer.

[0060] In this embodiment, the second subkey, derived from the second key, is a key component specifically used for protecting device identity privacy. Its function is to enable the device to communicate using a variable, random address, while the receiver can use this key to decipher the device's true identity, preventing long-term tracking. For example, in the Bluetooth Low Energy protocol, the second subkey is IRK.

[0061] In this embodiment, a preset key derivation function can be used to encrypt the first key, device address identifier, and session random number to obtain a first subkey. Then, the same key derivation function can be used to encrypt the first key, device address identifier, and privacy parameters to obtain the first subkey.

[0062] In this embodiment, the key derivation function (KDF) is a cryptographic primitive that takes at least one high-entropy secret value (such as a first key) and several variable parameters (such as cooperative parameters) as input, and generates one or more cryptographically strong output keys (second keys) through a deterministic encryption algorithm. The computation process of the key derivation function is deterministic, unidirectional (difficult to reverse-derive the input), and the output key has good randomness. Specifically, the encryption algorithm can employ algorithms such as HMAC (Hash-based Message Authentication Code) or CMAC (Cipher-based Message Authentication Code).

[0063] For example, when the first subkey is LTK and the second subkey is IRK, if the HMAC-SHA256 algorithm is used for encryption, then LTK = Truncate(HMAC-SHA256(Link_Key, MAC_A||MAC_B||Nonce), 128), IRK = Truncate(HMAC-SHA256(Link_Key, MAC_A||MAC_B||PrivacyParam), 128). Here, Link_Key represents the first key, MAC_A represents the MAC address of the first device, MAC_B represents the MAC address of the second device, Nonce represents the session random number, PrivacyParam represents the privacy parameter, "||" indicates concatenation, and Truncate indicates truncating to a specified length, such as 128 bits.

[0064] In this embodiment, by generating independent first and second subkeys, not only is rapid recovery of cross-protocol connections achieved, but a dual security mechanism of link encryption and privacy protection is also established simultaneously, significantly enhancing the scalability and practicality of the solution.

[0065] In one feasible implementation, after generating the second key based on the coordination parameters and the first key corresponding to the second connection, the communication method further includes the following steps: exchanging verification information for the second key with the second device through a secure channel; and storing the second key in a local secure storage area when it is determined from the verification information that the second keys of the first device and the second device are consistent.

[0066] In this embodiment, after the first device generates a second key (denoted as K2_A) locally, it immediately uses a predetermined verification algorithm (such as calculating a hash value or message authentication code) to generate verification information V_A in combination with the second key itself or a portion thereof. For example, V_A = Hash(K2_A). Subsequently, the first device sends V_A to the second device through an established, secure second connection channel. Simultaneously, the second device performs the same operation, generating verification information V_B based on its local second key K2_B and sending it to the first device. After receiving the verification information V_B from the second device, the first device compares it byte-by-byte with its local V_A. Similarly, the second device compares the received V_A with its local V_B. If V_A == V_B, both parties determine that the second keys of the first and second devices are consistent. This proves that the cooperative parameters input by both parties are exactly the same, and the KDF calculation process is correct, thus K2_A = K2_B. If V_A != V_B, either party determines that the second keys of the first and second devices are inconsistent. This usually means that the two parties failed to reach a true consensus on all parameters in previous parameter coordination.

[0067] In this embodiment, the generated second key K2_A is transferred from the temporary computation buffer to the local secure storage area for persistent storage only when the first device locally determines that the second keys of the two communicating parties are consistent. When the first device locally determines that the second keys of the two communicating parties are inconsistent, the second key K2_A and all related intermediate computation data are immediately and completely cleared (zeroed) from memory, and optionally, an error is reported to the upper-layer system or a retry mechanism is triggered.

[0068] In this embodiment, during the derivation and storage of the second key, all sensitive parameters can be erased using memory encryption and erasure techniques to prevent intermediate data leakage. Random delays or runtime perturbations are added to the execution flow of the derived function to enhance resistance to side-channel attacks.

[0069] In practical implementation, sensitive parameters can be erased when data erasure conditions are met. These sensitive parameters include at least one of the following: the first key serving as the root key, the second key generated during the derivation process and all its intermediate state variables, the session random number, and any plaintext data payload containing the key or parameters. Data erasure conditions may include: the second key being stored in a local secure storage area; after the verification information has been sent; or in the event of any failure or abnormal path (such as verification inconsistency or communication interruption).

[0070] In this embodiment, by performing an interactive verification operation based on a secure channel after the second key is derived, key inconsistencies caused by parameter negotiation errors or man-in-the-middle attacks can be effectively detected and defended against, ensuring the absolute consistency of keys between the communicating parties. Furthermore, by storing the second key in the local secure storage area only after successful verification, the security and reliability of the entire key recovery process are improved, providing crucial protection for applications with high security requirements. In addition, memory encryption and deterministic erasure techniques can be used to protect the data security of sensitive parameters.

[0071] In one feasible implementation, the verification information of the second key can be generated in the following way: generating target confirmation information based on the first address identifier of the first device and the second address identifier of the second device; performing a hash operation on the second key and the target confirmation information to obtain the verification information.

[0072] In this embodiment, target confirmation information refers to a data block jointly constructed by the first and second devices based on target data (such as device address identifiers of both parties) known to both parties, according to predetermined calculation rules. Target confirmation information can serve as a "salt value" or "additional data" for generating verification information, providing a unique context label that can be independently reproduced by both parties for this specific recovery session.

[0073] In this embodiment, the first device and the second device are local and can execute the same predefined calculation rules respectively, taking the first address identifier and the second address identifier as input to calculate and generate target confirmation information.

[0074] In this embodiment, the calculation rule can be a concatenation operation. For example, the calculation rule is defined as: M=Addr_A||Addr_B, where M represents the target confirmation information, Addr_A represents the first address identifier, and Addr_B represents the second address identifier.

[0075] In this embodiment, the calculation rule can use bitwise operations. For example, the calculation rule is defined as: M = Addr_AXOR Addr_B, where XOR represents bitwise XOR operation.

[0076] In this embodiment, M is generated using a unique address identifier inherent to both devices, ensuring that M is exclusive to both the first and second devices. Even if the same two devices perform recovery at different times, M remains unchanged, thereby preventing the second key from being misused by other devices.

[0077] In this embodiment, since the first address identifier and the second address identifier are known information exchanged and stored by both parties during the pairing phase, and the calculation rules are pre-agreed, both parties can independently and reliably generate identical M without any additional communication. This is the basis for subsequent effective verification.

[0078] In this embodiment, both the first and second devices can use the same hash algorithm (taking HMAC-SHA256 as an example) locally, using the second key K2 as the HMAC key and the target confirmation information M as the HMAC message for calculation. The first device calculates: V_A = HMAC - SHA256(K2, M), and the second device calculates: V_B = HMAC - SHA256(K2, M).

[0079] In this embodiment, by deterministically generating target confirmation information based on inherent device address identifiers, a strong binding between the verification process and a specific device pair is achieved without additional negotiation overhead. By employing hash operations based on the second key and the target confirmation information to generate the final verification value, this verification information can not only detect any differences in the second key with extreme sensitivity, but also effectively prevent forgery. Thus, the reliability, security, and operability of the verification stage in the entire key recovery process are significantly improved.

[0080] In one feasible implementation, the step of resuming data communication with the second device based on the first communication protocol based on the second key may specifically include: encrypting the target data using the second key to obtain an encrypted data packet; and sending the encrypted data packet through the broadcast channel of the first communication protocol so that when the second device hears the encrypted data packet, it can decrypt the encrypted data packet based on the second key that the second device has synchronized to obtain the target data.

[0081] In this embodiment, the second key includes a first subkey and a second subkey. For example, the first subkey can be an LTK, and the second subkey can be an IRK. The first device can use the synchronized LTK to derive the encryption key for the current session, encrypt the target data, and calculate the message authentication code to ensure integrity. Simultaneously, for privacy protection and to prevent tracking, the first device can use the synchronized IRK to generate a resolvable private address as the sender address for broadcast packets. Furthermore, an incrementing message sequence number and a current timestamp are added to the data packet. Specifically, the format of the encrypted data packet may include: an encrypted payload, a message sequence number, a timestamp, and a signature / hash field.

[0082] In this embodiment, the first device periodically sends the encapsulated encrypted data packets, according to the protocol specifications of the first communication protocol, on one or more preset broadcast channels at certain time intervals. This process does not require initiating a connection request to the second device.

[0083] In this embodiment, a broadcast channel refers to a public wireless communication channel in the first communication protocol that allows a device to actively send data without establishing a point-to-point connection, while allowing other devices to passively listen in and receive data. For example, in the Bluetooth Low Energy protocol, it specifically refers to three fixed broadcast physical channels.

[0084] It should be noted that traditional data transmission typically involves a complex process of "scanning - initiating a connection - parameter negotiation (including key distribution) - data exchange". In this embodiment, with the second key already securely pre-synchronized, secure data transmission is directly achieved using a broadcast channel, eliminating all link-layer connection establishment and management overhead, and enabling millisecond-level communication recovery.

[0085] In this embodiment, the second device initiates a scanning and listening mode on a channel where the first device is expected to broadcast. The second device checks the sender address of each received encrypted data packet. For example, it uses a synchronized IRK to parse all monitored private addresses. Only when the parsed identity information matches the first device's real identity is the encrypted data packet determined to originate from the first device, and it is captured. Otherwise, the packet is discarded. For captured encrypted data packets, the second device derives the same session decryption key using a synchronized LTK and decrypts the data packets. Simultaneously, it verifies the message authentication code and checks if the message sequence number and timestamp are within an acceptable window (to prevent replay). After all verifications are successful, the second device submits the decrypted target data to the upper-layer application to execute the corresponding business logic.

[0086] In this embodiment, by pre-synchronizing the second key between the first device and the second device, communication between the first device and the second device can be restored in a timely manner through a broadcast channel based on the first communication protocol. This not only improves the communication restoration efficiency but also ensures that the security of broadcast communication is no less than that of the traditional connection mode, thereby significantly improving the user experience after the connection is interrupted and achieving seamless communication restoration.

[0087] In one example, refer to Figure 2 This diagram illustrates the interaction process between a first device and a second device. Device A (the first device) and device B (the second device) are dual-mode Bluetooth devices supporting both BR / EDR and BLE protocols. The interaction process for restoring cross-protocol connectivity between device A and device B may include the following stages: Phase 1: Second Communication Protocol (BR / EDR) Pairing and First Key Establishment. Device A, as the initiator, sends a pairing request to Device B based on Classic Bluetooth BR / EDR. Device B responds and performs two-way authentication. After successful pairing, both devices generate and securely store the same Link Key locally, which serves as the first key for subsequent secure communication.

[0088] Phase 2: Bluetooth Low Energy (BLE) Connection Attempt and Anomaly Detection. Device A attempts to establish a Bluetooth Low Energy (BLE) connection or initiate BLE pairing with Device B. If an abnormal state such as BLE connection or pairing failure or timeout is detected, the anomaly recovery process is immediately triggered.

[0089] Phase 3: Parameter coordination via a secure channel using the second communication protocol. Device A uses the established, secure BR / EDR connection as a channel to send a recovery request and coordination parameters (which may include Device A's MAC address, a random number (Nonce), protocol version, etc.) to Device B. Device B responds through the same secure channel, potentially confirming, supplementing, or negotiating the parameters. Ultimately, both parties agree on a complete set of coordination parameters used for key derivation.

[0090] Phase 4: Both parties independently perform local key derivation. Device A and Device B, locally, use the same Key Derivation Function (KDF), taking the Link Key (first key) stored in Step 1 and the agreed-upon coordination parameters from Step 3 as inputs, and independently perform calculations. Both parties derive a second key for BLE communication. This second key mainly includes a Long-Term Key (LTK) for encryption and an Identity Resolution Key (IRK) for privacy protection.

[0091] Phase 5: Key Consistency Verification. To ensure that the derived keys from both parties are completely consistent, Device A and Device B exchange verification information (such as hash values ​​or digital signatures) generated from the newly derived keys via the BR / EDR secure channel. Both parties verify locally whether the received verification information matches the locally calculated information. If they match, the key synchronization is confirmed to be successful; if they do not match, the process terminates or returns to Step 3 for renegotiation.

[0092] Phase 6: Resumption of data communication using the second key based on the first communication protocol. The sending end (Device A) encrypts the service data using the synchronized LTK key and encapsulates it into data packets conforming to the BLE broadcast format, periodically transmitting them through the BLE broadcast channel. This process does not require establishing a standard BLE connection with Device B. The receiving end (Device B) continuously listens to the designated BLE broadcast channel. Upon capturing an encrypted broadcast packet from Device A, it uses the synchronized IRK to identify the device and the synchronized LTK for decryption and integrity verification. After successful verification, Device B extracts the service data and submits it to the upper-layer application for processing, thus restoring the service functionality.

[0093] Phase 7: Communication Recovery and Session Management. Both parties enter a stable encrypted communication state. The system automatically manages the recovered session, including maintaining the communication state and handling potential subsequent anomalies. Depending on the communication results, necessary confirmations or feedback may be required through secure channels or application-layer protocols to complete the entire recovery loop.

[0094] Through the above interaction, when the BLE connection between device A and device B is abnormal, the existing BR / EDR secure channel is used to quickly and securely derive a second key, and data communication is restored through a broadcast mechanism. This bypasses the traditional lengthy reconnection and pairing process, and achieves efficient, automatic, and user-unnoticed connection restoration.

[0095] To facilitate better implementation of the communication method of this application, this application also provides a communication device based on the above-described communication method. The meanings of the terms used are the same as in the above-described communication method, and specific implementation details can be found in the descriptions of the method embodiments.

[0096] Based on the same inventive concept, and referring to Figure 3 This application provides a communication device 300, which is used in a first device. The communication device 300 includes: The parameter coordination module 301 is used to coordinate parameters with the second device through a secure channel established by the second connection established with the second device based on the second communication protocol when a first connection anomaly is detected between the first communication protocol and the second device, and obtain coordinated parameters. The key generation module 302 is used to generate a second key based on the coordination parameters and the first key corresponding to the second connection; The communication recovery module 303 is used to restore data communication with the second device based on the first communication protocol, using the second key.

[0097] In one embodiment, the first communication protocol is Bluetooth Low Energy, the second communication protocol is Bluetooth Classic, and the first key is a connection key generated based on pairing using Bluetooth Classic.

[0098] In one embodiment, the collaboration parameters include at least one of a device address identifier, a session random number, and a privacy parameter; the device address identifier includes a first address identifier of a first device and a second address identifier of a second device.

[0099] In one embodiment, the second key includes at least one of a first subkey and a second subkey, wherein the first subkey is used for encryption of the first communication protocol link, and the second subkey is used for device privacy protection; the key generation module 302 includes: The first generation submodule is used to perform encryption operations on the first key, device address identifier and session random number to obtain the first subkey; The second generation submodule is used to perform encryption operations on the first key, device address identifier, and privacy parameters to obtain the first subkey.

[0100] In one embodiment, the communication device 300 further includes: The information exchange module is used to exchange verification information for the second key with the second device through a secure channel; The key storage module is used to store the second key in a local secure storage area when it is determined from the verification information that the second keys of the first device and the second device are consistent.

[0101] In one embodiment, the verification information for the second key is generated in the following manner: Based on the first address identifier of the first device and the second address identifier of the second device, target confirmation information is generated; The second key and the target confirmation information are hashed to obtain the verification information.

[0102] In one embodiment, the communication recovery module 303 includes: The encryption submodule is used to encrypt the target data using a second key to obtain an encrypted data packet; The data transmission submodule is used to send encrypted data packets through the broadcast channel of the first communication protocol, so that when the second device listens to the encrypted data packets, it can decrypt the encrypted data packets based on the second key that the second device has synchronized, and obtain the target data.

[0103] The technical solution adopted in this application intelligently utilizes the secure channel established through the second communication protocol for parameter coordination when an anomaly in the first communication protocol connection is detected, and locally derives a second key based on the existing first key, ultimately achieving rapid and automatic recovery of data communication in the first communication protocol. This avoids the drawbacks of traditional solutions that require users to manually reconnect or re-execute the complete key negotiation process, significantly improving the connection reliability, recovery speed, and user experience of the device in complex wireless environments.

[0104] Specific limitations regarding the communication device 300 can be found in the limitations regarding the communication method described above, and will not be repeated here. Each module in the aforementioned communication device 300 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in the computer device, or stored in software in the memory of the computer device, so that the processor can call and execute the operations corresponding to each module.

[0105] In addition, this application also provides an electronic device, such as Figure 4 As shown, it illustrates the structural diagram of the electronic device involved in this application, specifically: The electronic device may include components such as a processor 401 with one or more processing cores and a memory 402 with one or more computer-readable storage media. Those skilled in the art will understand that... Figure 4 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 401 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 402, and by calling data stored in the memory 402, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Optionally, the processor 401 may include one or more processing cores; preferably, the processor 401 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 401.

[0106] The memory 402 can be used to store software programs and modules. The processor 401 executes various functional applications and data processing by running the software programs and modules stored in the memory 402. The memory 402 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 402 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, or other volatile solid-state storage device. Accordingly, the memory 402 may also include a memory controller to provide the processor 401 with access to the memory 402.

[0107] In one feasible implementation, the electronic device further includes a power supply 403 that supplies power to the various components. Preferably, the power supply 403 can be logically connected to the processor 401 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 403 may also include one or more DC or AC power supplies, recharging systems, power equipment debugging circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0108] In one feasible implementation, the electronic device may further include an input unit 404, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0109] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 401 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 402 according to the following instructions, and the processor 401 runs the applications stored in the memory 402, thereby realizing the steps in any of the communication methods provided in the embodiments of this application.

[0110] Those skilled in the art will understand that Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0111] In one feasible implementation, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the methods described in any embodiment of this application.

[0112] In one feasible implementation, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the methods described in any embodiment of this application.

[0113] In one feasible implementation, a computer program product is also proposed, comprising a computer program or instructions that, when executed by a processor, implement the methods described in any embodiment of this application.

[0114] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0115] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0116] Therefore, this application provides a computer-readable storage medium storing a computer program that can be loaded by a processor to execute the steps of any of the communication methods provided in this application.

[0117] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0118] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0119] Since the instructions stored in the computer-readable storage medium can execute the steps of any of the communication methods provided in this application, the beneficial effects that any of the communication methods provided in this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

[0120] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes the element.

[0121] The foregoing has provided a detailed description of a communication method, apparatus, electronic device, and computer-readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A communication method, characterized in that, When applied to a first device, the method includes: When an anomaly is detected in the first connection between the first communication protocol and the second device, the parameters are coordinated with the second device through a secure channel established by the second connection between the second communication protocol and the second device to obtain the coordination parameters. A second key is generated based on the collaboration parameters and the first key corresponding to the second connection; Based on the second key, data communication with the second device based on the first communication protocol is resumed.

2. The communication method according to claim 1, characterized in that, The first communication protocol is Bluetooth Low Energy, and the second communication protocol is Bluetooth Classic; the first key is a connection key generated based on pairing using the Bluetooth Classic protocol.

3. The communication method according to claim 1, characterized in that, The collaboration parameters include at least one of device address identifier, session random number, and privacy parameters; the device address identifier includes a first address identifier of the first device and a second address identifier of the second device.

4. The communication method according to claim 3, characterized in that, The second key includes at least one of a first subkey and a second subkey, wherein the first subkey is used for encryption of the first communication protocol link and the second subkey is used for device privacy protection; The step of generating a second key based on the collaboration parameters and the first key corresponding to the second connection includes: The first subkey is obtained by performing encryption operations on the first key, the device address identifier, and the session random number; And / or, The first subkey is obtained by performing encryption operations on the first key, the device address identifier, and the privacy parameters.

5. The communication method according to claim 1, characterized in that, After generating the second key based on the collaboration parameters and the first key corresponding to the second connection, the method further includes: The second device exchanges verification information for the second key through the secure channel; When it is determined that the second keys of the first device and the second device are consistent based on the verification information, the second key is stored in the local secure storage area.

6. The communication method according to claim 5, characterized in that, The verification information for the second key is generated in the following manner: Based on the first address identifier of the first device and the second address identifier of the second device, target confirmation information is generated; The second key and the target confirmation information are hashed to obtain the verification information.

7. The communication method according to claim 1, characterized in that, The step of resuming data communication with the second device based on the first communication protocol, using the second key, includes: The target data is encrypted using the second key to obtain an encrypted data packet; The encrypted data packet is sent through the broadcast channel of the first communication protocol, so that when the second device listens to the encrypted data packet, it can decrypt the encrypted data packet based on the second key that the second device has synchronized, and obtain the target data.

8. A communication device, characterized in that, Applied to a first device, the device includes: The parameter coordination module is used to coordinate parameters with the second device through a secure channel established by the second connection based on the second communication protocol when a first connection anomaly between the second device and the first communication protocol is detected, so as to obtain coordinated parameters. A key generation module is used to generate a second key based on the collaboration parameters and the first key corresponding to the second connection; The communication recovery module is used to restore data communication with the second device based on the first communication protocol, using the second key.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the communication method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the communication method as described in any one of claims 1 to 7.

Images