Safety connection method based on distributed soft bus of honghong and related equipment
Patent Information
- Application Number
- CN202611404348.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-09-10
- Publication Date
- 2026-10-13
AI Technical Summary
[0003]当现有技术的标准化连接流程被部署于微波通信信道场景中时,微波信道固有的高传输时延、信号衰减以及易受干扰特性,会与原本面向低时延链路设计的多轮握手机制和复杂安全运算相互叠加,而现有软总线又缺乏对信道状态的实时感知能力以及协同设备间的链路调度与中继转发机制,使单一传输路径一旦受到干扰便容易发生连接中断或握手失败
[0018]上述基于鸿蒙分布式软总线的安全连接方法及相关设备所提供的一个方案中,本发明对微波信道的传输时延、信噪比和信号衰减量进行实时采集并据此对软总线握手参数进行档位匹配,使握手包字段配置、调制方式等连接参数能够依据信道状态预先固化于本地,避免了握手过程中重复进行参数协商;本发明基于信道状态对协同设备进行链路评分与中继节点筛选,并结合设备分布方式匹配相应的协同拓扑结构,使数据传输路径能够在原有点对点链路受扰时转换为经由中继节点的多跳路径,提升了连接抗干扰能力。本发明将预配置参数表与协同抗干扰策略共同作为三轮握手的执行依据,且在握手过程中一旦检测到信噪比低于干扰阈值即可对封装参数进行动态调整,使握手流程本身具备应对信道波动的自适应能力。本发明采用基于预共享密钥的轻量化认证方式,并对关键设备引入临时密钥协商机制生成会话密钥,结合分片并行加密与校验码核验,使认证与加密运算更适配微波终端有限的运算能力。本发明通过将权限校验结果与连接标识直接绑定,对超出授权范围的操作触发连接冻结与告警,将身份认证、数据加密与权限管控整合为统一的闭环管控流程,避免了认证通过后脱离权限约束执行操作的安全漏洞。
Smart Images

Figure CN122909048A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of soft bus connectivity technology, and in particular to a secure connection method and related equipment based on HarmonyOS distributed soft bus. Background Technology
[0002] The existing HarmonyOS distributed soft bus technology adopts a standardized handshake process with fixed rounds during the device connection establishment process. The encapsulation format, field length, and certificate chain verification or asymmetric encryption operation required for identity authentication of the handshake packet are all preset according to unified rules and will not be adjusted differently according to the real-time status of the underlying transmission channel.
[0003] When the standardized connection process of existing technologies is deployed in microwave communication channel scenarios, the inherent high transmission delay, signal attenuation and susceptibility to interference of microwave channels will be superimposed on the multi-round handshake mechanism and complex security calculation originally designed for low-latency links. Furthermore, the existing soft bus lacks the ability to perceive the channel status in real time and the link scheduling and relay forwarding mechanism between cooperative devices, making it easy for a single transmission path to experience connection interruption or handshake failure once it is interfered with. Summary of the Invention
[0004] This invention provides a secure connection method and related devices based on HarmonyOS distributed soft bus. This invention integrates identity authentication, data encryption and access control into a unified closed-loop management process, avoiding the security vulnerability of performing operations without permission constraints after authentication.
[0005] In a first aspect, embodiments of this application provide a secure connection method based on the HarmonyOS distributed soft bus, including: Collect channel state data of microwave channels, and match the local pre-configured parameter table and collaborative anti-interference strategy of HarmonyOS distributed soft bus according to the channel state data; Based on the local pre-configured parameter table and the cooperative anti-interference strategy, the initiating device and the receiving device perform a three-round handshake interaction to generate a connection completion packet. The encrypted session key fragment in the connection completion packet is authenticated to obtain the session key, and the data to be transmitted is encrypted based on the session key to obtain encrypted data; Based on the permission request digest in the connection completion packet, the permissions of the operation requested by the initiating device are compared to obtain the permission verification result. Based on the permission verification result, the soft bus connection corresponding to the connection completion packet is allowed or frozen.
[0006] Optionally, in a first implementation of the first aspect of the present invention, the step of collecting channel state data of the microwave channel and matching the local pre-configured parameter table and cooperative anti-interference strategy of the HarmonyOS distributed soft bus according to the channel state data includes: The transmission delay of the microwave channel is calculated based on the timestamp of the probe messages exchanged between the initiating device and the receiving device, and the received signal is demodulated based on the transmission delay to obtain the signal-to-noise ratio and signal attenuation of the microwave channel. The transmission delay, the signal-to-noise ratio, and the signal attenuation are combined to form the channel state data of the microwave channel; Match the local pre-configuration parameter table of HarmonyOS distributed soft bus based on the channel state data; Based on the channel state data, link scoring and relay selection are performed on the collaborative devices managed by the HarmonyOS distributed soft bus to obtain a collaborative anti-interference strategy.
[0007] Optionally, in a second implementation of the first aspect of the present invention, the step of matching the local pre-configuration parameter table of the HarmonyOS distributed soft bus according to the channel state data includes: The channel scene level is determined based on the transmission delay and signal-to-noise ratio in the channel state data. The channel scene level includes high bandwidth scene, medium bandwidth scene and low bandwidth scene. Based on the channel scenario level, the handshake packet field configuration, transmission rate, modulation method, channel bandwidth, maximum transmission unit, retry limit, acknowledgment timeout duration, transmission control window and sliding window packet quantity corresponding to the HarmonyOS distributed soft bus are matched to generate a local pre-configuration parameter table, and the local pre-configuration parameter table is written to the local storage medium.
[0008] Optionally, in a third implementation of the first aspect of the present invention, the step of performing link scoring and relay selection on the collaborative devices managed by the HarmonyOS distributed soft bus based on the channel state data to obtain a collaborative anti-interference strategy includes: The relay score is calculated based on the signal reception strength, remaining power, and processor load of the collaborative devices in the HarmonyOS distributed soft bus management system. Construct a link quality matrix between the cooperating devices based on the relay score; When the signal-to-noise ratio in the channel state data is lower than a preset interference threshold, the cooperative device with the highest relay score is selected from the link quality matrix as a relay node and a cooperative anti-interference strategy is generated.
[0009] Optionally, in a fourth implementation of the first aspect of the present invention, the step of selecting the cooperating device with the highest relay score from the link quality matrix as a relay node and generating a cooperative anti-interference strategy when the signal-to-noise ratio in the channel state data is lower than a preset interference threshold includes: The signal-to-noise ratio in the channel state data is compared with a preset interference threshold; When the signal-to-noise ratio in the channel state data is lower than a preset interference threshold, the cooperative device with the highest relay score is selected as the relay node from the link quality matrix; Based on the relay node, the original point-to-point transmission path between the initiating device and the receiving device is reconstructed to obtain a multi-hop transmission path forwarded by the relay node. The collaborative topology is matched according to the distribution mode of the collaborative devices managed by the HarmonyOS distributed soft bus, and a collaborative anti-interference strategy is generated based on the multi-hop transmission path and the collaborative topology.
[0010] Optionally, in a fifth implementation of the first aspect of the present invention, the step of performing a three-round handshake interaction between the initiating device and the receiving device according to the local pre-configured parameter table and the cooperative anti-interference strategy to generate a connection completion packet includes: Based on the handshake packet field configuration in the local pre-configured parameter table, the device identifier of the initiating device, the local pre-configured parameter table summary, and the simplified identity credential are encapsulated to obtain a connection request packet, and the connection request packet is sent to the receiving device. The receiving device compares and verifies the simplified identity credential based on the pre-shared key stored locally. After the comparison and verification are successful, the receiving device's device identifier, parameter confirmation information, and lightweight digital signature are encapsulated to obtain a response confirmation packet, which is then returned to the initiating device. The initiating device verifies the lightweight digital signature in the response confirmation packet. After the signature verification is successful, it encapsulates the encrypted session key fragment and the permission request digest to obtain a connection completion packet, and sends the connection completion packet to the receiving device.
[0011] Optionally, in a sixth implementation of the first aspect of the present invention, during the handshake interaction, the signal-to-noise ratio continuously monitored by the collaborative anti-interference strategy is compared with a preset interference threshold. When the signal-to-noise ratio continuously monitored by the cooperative anti-interference strategy is lower than the preset interference threshold, a channel quality degradation event is triggered. According to the event response mapping table in the cooperative anti-interference strategy, the encapsulation parameters of the connection completion packet are switched to the corresponding robust transmission parameters to obtain the adjusted connection completion packet, and the adjusted connection completion packet is sent to the receiving device. The receiving device verifies the encrypted session key fragment and permission request digest in the received adjusted connection completion packet based on the locally stored verification information, and generates a verified connection completion packet.
[0012] Optionally, in a seventh implementation of the first aspect of the present invention, the step of authenticating the encrypted session key fragment in the connection completion packet to obtain a session key, and encrypting the data to be transmitted based on the session key to obtain encrypted data, includes: The simplified identity credentials of the initiating device are compared with the pre-shared key stored locally using hash digest. If the hash digests match, an identity authentication result is generated. When the receiving device is a pre-marked key device, scalar multiplication and exchange are performed on the local temporary private keys of the initiating device and the receiving device based on the pre-selected base point to obtain a temporary shared key. The temporary shared key is then combined with the encrypted session key fragment to obtain the session key. Based on the session key, the data to be transmitted is encrypted to obtain encrypted data, and a cyclic redundancy check (CRC) code for the encrypted data is calculated and appended to the encrypted data.
[0013] Optionally, in an eighth implementation of the first aspect of the present invention, the step of comparing the permissions of the operation requested by the initiating device based on the permission request digest in the connection completion packet to obtain a permission verification result, and then allowing or freezing the soft bus connection corresponding to the connection completion packet based on the permission verification result, includes: The operation type recorded in the permission request summary in the connection completion packet is compared with the permission range pre-configured for the initiating device to obtain the permission verification result. The permission verification result includes a legal result where the operation type is within the permission range and an unauthorized result where the operation type exceeds the permission range. When the permission verification result is valid, the soft bus connection corresponding to the connection completion packet is allowed to continue transmitting the encrypted data under the soft bus connection. When the permission verification result is an unauthorized result, the soft bus connection corresponding to the connection completion packet is frozen, the soft bus connection is disconnected, and a security alarm event is published through the distributed event bus.
[0014] Secondly, embodiments of this application provide a secure connection device based on the HarmonyOS distributed soft bus, including: The data acquisition subsystem is used to acquire channel status data of microwave channels and match the local pre-configured parameter table and collaborative anti-interference strategy of HarmonyOS distributed soft bus according to the channel status data. The handshake interaction subsystem is used to perform a three-round handshake interaction between the initiating device and the receiving device according to the local pre-configured parameter table and the cooperative anti-interference strategy, and generate a connection completion packet. The data encryption subsystem is used to authenticate the encrypted session key fragment in the connection completion packet to obtain the session key, and encrypt the data to be transmitted based on the session key to obtain encrypted data. The permission verification subsystem is used to compare the permissions of the operation requested by the initiating device based on the permission request digest in the connection completion packet, obtain the permission verification result, and allow or freeze the soft bus connection corresponding to the connection completion packet based on the permission verification result.
[0015] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the aforementioned secure connection method based on the HarmonyOS distributed soft bus.
[0016] Fourthly, embodiments of this application provide a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the aforementioned secure connection method based on the HarmonyOS distributed soft bus.
[0017] Fifthly, embodiments of this application provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the aforementioned secure connection method based on the HarmonyOS distributed soft bus.
[0018] In the aforementioned secure connection method and related equipment based on the HarmonyOS distributed soft bus, this invention collects the transmission delay, signal-to-noise ratio, and signal attenuation of the microwave channel in real time and matches the soft bus handshake parameters accordingly. This allows connection parameters such as handshake packet field configuration and modulation method to be pre-fixed locally based on the channel state, avoiding repeated parameter negotiation during the handshake process. Based on the channel state, this invention performs link scoring and relay node screening for collaborative devices and matches the corresponding collaborative topology with the device distribution method. This enables the data transmission path to be converted into a multi-hop path via relay nodes when the original point-to-point link is disturbed, improving the connection's anti-interference capability. This invention uses a pre-configured parameter table and collaborative anti-interference strategy as the execution basis for the three-round handshake. Furthermore, if the signal-to-noise ratio is detected to be below the interference threshold during the handshake process, the encapsulation parameters can be dynamically adjusted, giving the handshake process itself the ability to adapt to channel fluctuations. This invention adopts a lightweight authentication method based on a pre-shared key and introduces a temporary key negotiation mechanism to generate session keys for key devices. Combined with fragmented parallel encryption and checksum verification, this makes authentication and encryption operations more adaptable to the limited computing power of microwave terminals. This invention directly binds the permission verification result to the connection identifier, triggers connection freezing and alarms for operations that exceed the authorized scope, and integrates identity authentication, data encryption and permission control into a unified closed-loop management process, avoiding the security vulnerability of performing operations outside of permission constraints after authentication. Attached Figure Description
[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention 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.
[0020] Figure 1 This is a schematic diagram of a secure connection system based on HarmonyOS distributed soft bus in one embodiment of the present invention; Figure 2 This is a flowchart illustrating a secure connection method based on HarmonyOS distributed soft bus in one embodiment of the present invention; Figure 3 yes Figure 2 A schematic diagram of the implementation process of step S10; Figure 4 yes Figure 2 A schematic diagram of the implementation process of step S20; Figure 5 yes Figure 2 A schematic diagram of the implementation process of step S30; Figure 6 yes Figure 2A schematic diagram of the implementation process of step S40; Figure 7 This is a timing diagram of channel state awareness and cooperative anti-interference strategy generation in one embodiment of the present invention; Figure 8 This is a timing diagram of the three-round handshake and session key establishment in one embodiment of the present invention; Figure 9 This is a timing diagram of permission verification and soft bus connection control in one embodiment of the present invention; Figure 10 This is a schematic diagram of a secure connection device based on HarmonyOS distributed soft bus in one embodiment of the present invention; Figure 11 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention. Detailed Implementation
[0021] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0022] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. It should also be understood that, as used in this specification and the appended claims, the term "and / or" refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0023] Furthermore, in the description of this invention and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0024] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of the invention 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.
[0025] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.
[0026] To illustrate the technical solution of the present invention, specific embodiments are described below.
[0027] To address the problems mentioned above in the background technology, this application proposes a secure connection method and related devices based on the HarmonyOS distributed soft bus. The secure connection method based on the HarmonyOS distributed soft bus provided by this invention can be applied to applications such as... Figure 1 The secure connection system based on HarmonyOS distributed soft bus shown includes an initiating device 1; a receiving device 2; HarmonyOS distributed soft bus; a first channel sensing module; a handshake interaction module; a session encryption module; a permission request module; a second channel sensing module; a handshake verification module; a session key module; and a permission verification module.
[0028] In one embodiment, such as Figure 2 As shown, a secure connection method based on HarmonyOS distributed soft bus is provided, which is then applied to... Figure 1 Taking the secure connection system based on HarmonyOS distributed soft bus as an example, the following steps are included: S10: Collect channel status data of microwave channels and match the local pre-configured parameter table and collaborative anti-interference strategy of HarmonyOS distributed soft bus according to the channel status data; S20: Based on the local pre-configured parameter table and the cooperative anti-interference strategy, the initiating device and the receiving device perform a three-round handshake interaction to generate a connection completion packet; S30: Authenticate the encrypted session key fragment in the connection completion packet to obtain the session key, and encrypt the data to be transmitted based on the session key to obtain encrypted data; S40: Based on the permission request summary in the connection completion packet, compare the permissions of the operation requested by the initiating device to obtain the permission verification result, and allow or freeze the soft bus connection corresponding to the connection completion packet according to the permission verification result.
[0029] In this embodiment, the transmission delay, signal-to-noise ratio (SNR), and signal attenuation of the microwave channel are collected in real time, and the soft bus handshake parameters are matched accordingly. This allows connection parameters such as handshake packet field configuration and modulation method to be pre-fixed locally based on the channel status, avoiding repeated parameter negotiation during the handshake process. Link scoring and relay node selection are performed on the cooperating devices based on the channel status, and a corresponding cooperative topology is matched according to the device distribution. This enables the data transmission path to be converted into a multi-hop path via relay nodes when the original point-to-point link is disturbed, improving the connection's anti-interference capability. This invention uses a pre-configured parameter table and a cooperative anti-interference strategy as the basis for the execution of the three-round handshake. Furthermore, if the SNR is detected to be below the interference threshold during the handshake process, the encapsulation parameters can be dynamically adjusted, giving the handshake process itself the ability to adapt to channel fluctuations. A lightweight authentication method based on a pre-shared key is adopted, and a temporary key negotiation mechanism is introduced for key devices to generate session keys. Combined with fragmented parallel encryption and checksum verification, the authentication and encryption operations are better adapted to the limited computing power of the microwave terminal. By directly binding the permission verification result to the connection identifier, the connection is frozen and an alarm is triggered for operations that exceed the authorized scope. This integrates identity authentication, data encryption and permission control into a unified closed-loop management process, avoiding the security vulnerability of performing operations without permission constraints after authentication.
[0030] In one embodiment, such as Figure 3 As shown, step S10 specifically includes the following steps: S11: Calculate the transmission delay of the microwave channel based on the timestamp of the probe message exchanged between the initiating device and the receiving device, and demodulate the received signal based on the transmission delay to obtain the signal-to-noise ratio and signal attenuation of the microwave channel. S12: Combine transmission delay, signal-to-noise ratio, and signal attenuation into channel state data for the microwave channel; S13: Match the local pre-configuration parameter table of HarmonyOS distributed soft bus based on the channel state data; S14: Based on channel state data, perform link scoring and relay selection on collaborative devices managed by HarmonyOS distributed soft bus to obtain collaborative anti-interference strategies.
[0031] In this embodiment, before establishing a soft bus connection, the initiating device calls the microwave communication module to send a probe message, and writes the probe sequence number, initiating device identifier, sending timestamp, and channel sampling identifier into the message header. After receiving the probe message, the receiving device records the receiving timestamp and carries the receiving timestamp, receipt sending timestamp, and received signal sampling result in the acknowledgment message. The initiating device then records the acknowledgment arrival timestamp, thus forming a complete probe interaction process. In order to reduce the error caused by the clock asynchrony between the two ends, multiple short probe messages can be sent continuously, and obviously abnormal timestamp samples can be removed. The average delay or median delay of the stable samples is then used as the transmission delay τ of the current microwave channel. The common transmission delay of microwave channels is in the range of 100-500ms. Therefore, when sampling, the probe period needs to be set to a short period that is less than the allowed connection establishment time so that the channel state can be updated before the formal handshake. The receiving device aligns the sampling window of the received signal according to the transmission delay, sends the received signal into the corresponding demodulation link, and estimates the effective signal power and noise power by combining pilot symbols, synchronization sequences, or known probe sequences to obtain the signal-to-noise ratio (SNR). Simultaneously, it determines the signal attenuation A based on the preset transmit power on the initiating side, the received power measured on the receiving side, and the link gain compensation result. Here, τ represents the transmission delay obtained from the probe interaction, SNR represents the strength of the effective signal relative to the noise in the received signal, and A represents the degree of signal attenuation in the microwave transmission path. τ, SNR, and A are bound together according to the same sampling time, the same probe sequence number, and the same device to generate channel state data for the microwave channel. This data is written to the state cache maintained by the soft bus fast connection engine, and the sampling time, validity period, and anomaly flag are appended to prevent the connection process from using expired or abnormal states.The fast connection engine matches locally pre-configured parameter tables based on channel state data. For example, when τ≤200ms and SNR≥20dB, it can be identified as a high-bandwidth scenario, using more complete handshake packet fields, a transmission rate of 20-40Mbps, 64QAM modulation, 40MHz channel bandwidth, 1500-byte MTU, a 7-retry limit, a 100ms ACK timeout, a 65535-byte TCP window, and a 64-packet sliding window. When 200ms<τ≤500ms and 10dB≤SNR<20dB, it can be identified as a medium-bandwidth scenario, using simplified fields, a transmission rate of 5-20Mbps, 16QAM modulation, 20MHz channel bandwidth, 1024-byte MTU, a 10-retry limit, and a 200ms handshake packet. The system employs ACK timeout, a 32768-byte TCP window, and a sliding window of 32 packets. When τ > 500ms and SNR < 10dB, it can be identified as a low-bandwidth scenario. This allows for the pre-fixing of handshake fields, transmission rates, modulation schemes, MTU, and acknowledgment strategies before the formal connection is established, reducing the need for additional parameter negotiation. Meanwhile, the soft bus collects the capabilities of the collaborative devices within its management scope, reading the signal reception strength, remaining power, and processor load of each collaborative device. These states are used for link scoring and relay selection. Devices with higher signal reception strength, more remaining power, and lower processor load are more suitable as relay nodes. When the SNR is lower than the preset interference threshold, the system selects the collaborative device with the highest relay score from the link quality matrix, reconstructs the original point-to-point link between the initiating device and the receiving device into a multi-hop transmission path forwarded by the relay node, and matches the device distribution method with star, mesh, or chain collaborative topologies to form a collaborative anti-interference strategy.
[0032] In one embodiment, step S13 specifically includes the following steps: The channel scenario level is determined based on the transmission delay and signal-to-noise ratio in the channel state data. The channel scenario levels include high bandwidth scenario, medium bandwidth scenario and low bandwidth scenario. Based on the channel scenario level, the handshake packet field configuration, transmission rate, modulation method, channel bandwidth, maximum transmission unit, retry limit, acknowledgment timeout duration, transmission control window and sliding window packet quantity corresponding to HarmonyOS distributed soft bus are matched to generate a local pre-configured parameter table, and the local pre-configured parameter table is written to the local storage medium.
[0033] In this embodiment, the fast connection engine reads the transmission delay τ and signal-to-noise ratio (SNR) from the channel state data and uses them as dual threshold judgment conditions. Because microwave links may simultaneously have high latency and low noise, or low latency but strong interference, the results of multiple consecutive samplings can be smoothed before judgment, and a short validity period can be set. Only samples that are still within the validity period are allowed to participate in the level matching. After determining the combined state of τ and SNR as the corresponding channel scenario level, the fast connection engine configures the handshake packet field, fragment payload length, maximum transmission unit, retry limit, acknowledgment timeout duration, transmission control window, and sliding window packet quantity according to the corresponding level parameters. The acknowledgment timeout duration is dynamically determined based on the smoothed round-trip delay, delay jitter, and processing margin. The transmission control window is dynamically determined based on the bandwidth-delay product formed by the target transmission rate and the round-trip delay, and the corresponding capability identifier is recorded synchronously when the window is expanded, the application layer sliding window is enabled, or the non-TCP transmission mechanism is enabled. The modulation method and channel bandwidth are selected by the microwave communication module according to the link adaptive strategy. The soft bus side only stores the transmission constraints and reliability control parameters corresponding to the current channel scenario level. If τ and SNR fall into different tiers, for example, τ meets the requirements of a medium bandwidth scenario while SNR is already below 10dB, parameters can be generated according to a more robust tier to avoid connection failures caused by pursuing higher speeds. Simultaneously, a hysteresis interval can be set for each tier to prevent frequent configuration rewriting when the channel fluctuates near the threshold. After determining the channel scenario tier, the fast connection engine encapsulates the tier identifier, handshake packet field configuration, rate, modulation scheme, bandwidth, maximum transmission unit, retry limit, acknowledgment timeout duration, transmission control window, sliding window packet count, and parameter version number into a local pre-configured parameter table, and generates a summary value for the local pre-configured parameter table. When writing the local pre-configured parameter table to the local storage medium, an atomic write method is used. That is, the temporary configuration area is written first, and then the parameter version and digest value are verified. After the verification is successful, the temporary configuration is switched to the currently effective configuration, while the previous version configuration is retained as a rollback item. In this way, even if the device loses power or the channel status changes suddenly during the writing process, the existing available parameters will not be destroyed. When initiating the soft bus handshake again, the initiator can directly read the parameter table to complete the handshake packet encapsulation and transmission parameter loading, thereby avoiding additional parameter negotiation, shortening the connection preparation time, and enabling the connection process to automatically enter the corresponding execution mode of high bandwidth, medium bandwidth, or low bandwidth according to the microwave channel status.
[0034] In one embodiment, step S14 specifically includes the following steps: The relay score is calculated based on the signal reception strength, remaining power, and processor load of the collaborative devices in the HarmonyOS distributed soft bus management system. Construct a link quality matrix between cooperating devices based on relay scores; When the signal-to-noise ratio in the channel state data is lower than the preset interference threshold, the cooperative device with the highest relay score is selected from the link quality matrix as the relay node and a cooperative anti-interference strategy is generated.
[0035] In this embodiment, the soft bus connection management side maintains a collaborative device status table and continuously updates the signal reception strength, remaining battery power, and processor load of each candidate device through device discovery, heartbeat messages, and link detection results. The signal reception strength reflects the wireless reception quality between the device and the current microwave link or surrounding nodes. The remaining battery power is used to determine whether the device has the continuous operating capability to undertake relay forwarding tasks. The processor load is used to determine whether the device will cause additional congestion when undertaking forwarding, verification, buffering, and retransmission processing. When calculating the relay score, the three statuses are normalized to convert data of different dimensions into comparable scoring factors. Then, a comprehensive evaluation is carried out according to the principle of "signal quality priority, energy status constraint, and processing load suppression". That is, the higher the signal reception strength, the more sufficient the remaining battery power, and the lower the processor load, the higher the corresponding relay score. For collaborative devices with low battery power, high load, or heartbeat timeout, even if their reception strength is good, the score should be reduced or they should be directly marked as unavailable to avoid the selected relay node from dropping the connection or having excessive forwarding delay during the connection establishment process. The relay scores of each cooperating device are written into the link quality matrix. The link quality matrix uses device identifiers as row and column indices to record the reachability relationships, scores, and link statuses between the initiating device, the receiving device, and candidate cooperating devices. During matrix updates, the sampling time, status version, and availability flag are synchronously written, allowing the fast connection engine to directly read the currently valid path quality information before the handshake, without needing to temporarily re-probe all nodes. Simultaneously, the link quality matrix can differentiate between star, mesh, and chain-like cooperative relationships based on device distribution, enabling path reconstruction to determine whether a device is located in a forwardable position between the initiator and receiver, rather than simply selecting a single device. When the signal-to-noise ratio in the channel state data falls below a preset interference threshold, the soft bus triggers a link interference judgment and selects the cooperating device with the highest relay score from the link quality matrix as a relay node. The original point-to-point transmission path is then switched to a multi-hop transmission path via the relay node, and a cooperative anti-interference strategy is generated. This strategy includes the relay node identifier, forwarding path, corresponding robust transmission parameters, retry control method, event response method, and backoff conditions.
[0036] In one embodiment, when the signal-to-noise ratio in the channel state data is lower than a preset interference threshold, the cooperating device with the highest relay score is selected from the link quality matrix as the relay node, and a cooperative anti-interference strategy is generated, including: The signal-to-noise ratio in the channel state data is compared with a preset interference threshold; When the signal-to-noise ratio in the channel state data is lower than the preset interference threshold, the cooperative device with the highest relay score is selected as the relay node from the link quality matrix; The original point-to-point transmission path between the initiating device and the receiving device is reconstructed based on the relay node to obtain a multi-hop transmission path forwarded by the relay node. The collaborative topology is matched according to the distribution mode of the collaborative devices managed by HarmonyOS distributed soft bus, and a collaborative anti-interference strategy is generated based on the multi-hop transmission path and the collaborative topology.
[0037] In this embodiment, after generating channel state data, the soft bus connection management side compares the signal-to-noise ratio (SNR) field with a locally stored preset interference threshold in real time. To avoid false triggering due to instantaneous noise, it performs smooth confirmation on several consecutive sampling results. Only when the SNR remains below the preset interference threshold is the current link marked as an disturbed link, and a relay selection request is sent to the path scheduling unit. Upon receiving the relay selection request, the path scheduling unit reads the records of cooperative devices in an available state from the link quality matrix and excludes devices with heartbeat timeouts, insufficient power, excessive load, or unreachable connections to the initiator or receiver. Then, it sorts the devices according to their relay scores from high to low, and determines the cooperative device with the highest score that can simultaneously connect to both the initiator and receiver devices as the relay node. If there are multiple candidate devices with similar scores, their link stability, historical packet loss status, and path hop count can be further compared to select the device with a shorter forwarding path, more up-to-date status update time, and less link fluctuation, ensuring that the relay selection result not only has a high score but also has actual forwarding capability. After determining the relay node, the soft bus rewrites the original direct connection record from "initiator device to receiver device" in the path table into a multi-hop transmission path from "initiator device to relay node to receiver device," and simultaneously updates the connection identifier, forwarding node identifier, packet sequence number mapping, retransmission responsibility boundary, and path validity period. This ensures that handshake packets, connection completion packets, and encrypted data can all be forwarded according to the new path. Simultaneously, the relay node needs to establish a temporary forwarding buffer locally to perform integrity verification, sequence number registration, and forwarding confirmation on received data frames, preventing out-of-order forwarding, duplicate forwarding, or lost confirmations under multi-hop paths. The corresponding cooperative topology is matched based on the distribution of the cooperating devices. If the devices are concentrated around the central node, a star topology is used to reduce scheduling complexity; if the devices are scattered and there are multiple selectable paths, a mesh topology is used to improve anti-interference redundancy; if the devices are arranged sequentially along line or area boundaries, a chain topology is used to maintain path continuity. The selected multi-hop transmission path, cooperative topology, robust transmission parameters, retry control method, path backoff conditions, and channel quality event response relationship are collectively encapsulated into a cooperative anti-interference strategy. After the collaborative anti-interference strategy is generated, it is written into the soft bus connection context and notified to the initiating device, the receiving device, and the relay node through a distributed event mechanism, so that each device uses the same forwarding rules within the same connection period. When the channel quality recovers to an acceptable state, the transmission path is smoothly switched back to the direct path according to the fallback conditions.
[0038] In one embodiment, such as Figure 4 As shown, step S20 specifically includes the following steps: S21: Based on the handshake packet field configuration in the local pre-configured parameter table, encapsulate the device identifier of the initiating device, the local pre-configured parameter table summary, and the simplified identity credential to obtain a connection request packet, and send the connection request packet to the receiving device; S22: The receiving device compares and verifies the simplified identity credential based on the pre-shared key stored locally. After the comparison and verification are successful, the receiving device's device identifier, parameter confirmation information and lightweight digital signature are encapsulated to obtain a response confirmation packet, and the response confirmation packet is returned to the initiating device. S23: The initiating device verifies the lightweight digital signature in the response confirmation packet. After the signature verification is successful, it encapsulates the encrypted session key fragment and the permission request digest to obtain the connection completion packet, and sends the connection completion packet to the receiving device.
[0039] In this embodiment, after entering the soft bus fast connection process, the initiating device reads the already effective local pre-configured parameter table and determines the fields, field order, field length, and compression method to be retained in the connection request packet based on the handshake packet field configuration. Then, it encapsulates the device identifier of the initiating device, the local pre-configured parameter table summary, and the simplified identity credential into a connection request packet. The device identifier is used to enable the receiver to identify the connection source, the parameter table summary is used to enable the receiver to quickly determine whether the handshake parameters currently used by both parties are consistent, and the simplified identity credential can be composed of the device model, the factory unique identifier, or pre-registered lightweight identity fields. In order to ensure that the request packet does not increase the retransmission probability due to too many fields when transmitted in the microwave link, the initiating device only carries the content necessary to complete the identity recognition and parameter consistency judgment, and adds the connection sequence number, timestamp, and integrity verification field to the packet header. Then, it sends the connection request packet to the receiving device according to the corresponding parameter level. Upon receiving the connection request packet, the receiving device verifies the packet sequence number, digest field, and integrity check result to confirm that the request has not been truncated, tampered with, or retransmitted. It then reads the pre-shared key from its local secure storage and uses it to compare and verify the simplified identity credential. If the simplified identity credential does not match the local registration information, the receiving device directly rejects the connection and records the anomaly. If the comparison and verification pass, it continues to compare the local pre-configured parameter table digest in the connection request packet with the receiving device's local parameter digest. If they match, it generates parameter confirmation information indicating that the parameters are available. If there are discrepancies, it can choose to accept the initiator's parameters, request a switch to local parameters, or return a result indicating parameter inconsistency, depending on the current channel state. After parameter confirmation, the receiving device encapsulates its own device identifier, parameter confirmation information, and a lightweight digital signature into a response confirmation packet. The lightweight digital signature proves that the response confirmation packet was indeed generated by the receiving device holding the pre-shared key and prevents attackers from forging the confirmation response. The receiving device then returns the response confirmation packet to the initiating device. After receiving the response confirmation packet, the initiating device verifies the source of the response based on the receiver device's identifier. It then uses locally stored verification information to verify the lightweight digital signature and checks the consistency of the parameter confirmation information. If signature verification fails or the parameter confirmation result does not meet the connection conditions, the initiating device aborts the handshake and clears the current connection context. If signature verification passes, it indicates that the receiver's identity is trustworthy and the handshake parameters have been agreed upon by both parties. The initiating device continues to generate an encrypted session key fragment and forms a permission request digest based on the currently requested operation type, operation object, and permission level. Then, it encapsulates the encrypted session key fragment and the permission request digest according to the field configuration of the connection completion packet to obtain the connection completion packet. The initiating device sends the connection completion packet to the receiver device, enabling the receiver device to authenticate the encrypted session key fragment, recover the key, and perform permission comparison based on the permission request digest.
[0040] In one embodiment, during the handshake interaction, the signal-to-noise ratio continuously monitored by the collaborative anti-interference strategy is compared with a preset interference threshold; When the signal-to-noise ratio continuously monitored by the cooperative anti-interference strategy is lower than the preset interference threshold, a channel quality degradation event is triggered. According to the event response mapping table in the cooperative anti-interference strategy, the encapsulation parameters of the connection completion packet are switched to the corresponding robust transmission parameters to obtain the adjusted connection completion packet, and the adjusted connection completion packet is sent to the receiving device. The receiving device verifies the encrypted session key fragment and permission request digest in the received adjusted connection completion packet based on the locally stored verification information, and generates a verified connection completion packet.
[0041] In this embodiment, during the period before the three-round handshake is completed, the initiating device and the receiving device continuously run the cooperative anti-interference strategy as a real-time monitoring thread in the handshake context. The microwave communication module reports the current signal-to-noise ratio according to the detection cycle, and the soft bus connection management side compares the current signal-to-noise ratio with the preset interference threshold. In order to avoid frequent rewriting of the connection completion packet caused by short-term spike noise, a continuous sampling confirmation and state maintenance mechanism can be added during the comparison. That is, only when the current signal-to-noise ratio is continuously lower than the preset interference threshold within the effective sampling window will the link state in the handshake context be switched from the normal transmission state to the quality degradation state, and a channel quality degradation event will be triggered through the distributed event bus. Once an event is triggered, the fast connection engine reads the pre-maintained event response mapping table in the collaborative anti-interference strategy, maps "channel quality degradation" to robust transmission actions, and switches the encapsulation parameters of the connection completion packet from the original corresponding level parameters to robust transmission parameters. Specifically, this may include compressing unnecessary extended fields, shortening the single packet payload, enhancing packet header verification, adjusting the acknowledgment and response strategy, increasing retransmission tolerance, and enabling relay path forwarding when necessary. However, it does not change the semantics of the two core security fields, the encrypted session key fragment and the permission request digest, in the connection completion packet, so as not to affect identity authentication and permission comparison. The initiating device regenerates the adjusted connection completion packet based on the new encapsulation parameters, and writes the original connection sequence number, adjustment identifier, policy version, path identifier, and integrity verification information into the packet header. This enables the receiving device to recognize that the connection completion packet is not a new connection request, but a robust encapsulation version generated due to channel quality degradation during the same handshake process. If a connection completion packet that has been generated but not yet sent is in the sending queue, the original queue entry is first removed and then the adjusted queue entry is written. If the original connection completion packet has been sent but no acknowledgment has been received, the adjusted connection completion packet is resent according to the robust transmission parameters, and the packet sequence number and policy version are used to prevent the receiver from establishing a connection repeatedly. Upon receiving the adjusted connection completion packet, the receiving device verifies the connection sequence number, initiator device identifier, parameter table digest, policy version, and integrity verification result based on locally stored verification information. This confirms that the connection completion packet belongs to the same connection context that has passed the first two rounds of handshake verification. Then, it performs a validity check on the encrypted session key fragment within it, determining whether it matches the lightweight digital signature result, pre-shared key verification result, and current session randomness in the preceding response confirmation packet. It also parses the permission request digest to confirm that its operation type, permission scope digest, and digest integrity have not been tampered with. When all the above verifications pass, the receiving device marks the adjusted connection completion packet as a verified connection completion packet and writes it into the soft bus connection context, continuing the session key recovery, data encryption, and permission verification process.
[0042] In one embodiment, such as Figure 5 As shown, step S30 specifically includes the following steps: S31: Compare the simplified identity credentials of the initiating device with the pre-shared key stored locally using hash digest. If the hash digests match, generate an identity authentication result. S32: When the receiving device is a pre-marked key device, perform scalar multiplication and exchange on the local temporary private keys of the initiating device and the receiving device based on the pre-selected base point to obtain a temporary shared key, and combine the temporary shared key with the encrypted session key fragment to obtain the session key; S33: Based on the session key, encrypt the data to be transmitted to obtain encrypted data, calculate the cyclic redundancy check code of the encrypted data, and append the cyclic redundancy check code to the encrypted data.
[0043] In this embodiment, after receiving the connection completion packet and confirming that it belongs to the same soft bus connection context, the receiving device traces back the simplified identity credential carried in the connection request packet, reads the pre-shared key corresponding to the pre-registration relationship with the initiating device from the local secure storage area, performs hash digest processing on the simplified identity credential, and compares the resulting digest with the digest generated or saved based on the local pre-shared key. If the comparison is inconsistent, it indicates that the initiating device may not hold a legitimate factory identity, the connection request has been tampered with, or there is a risk of impersonation. The receiving device immediately terminates the current identity authentication, clears the encrypted session key fragment and permission request digest in the current connection context, and records the anomaly through the soft bus security event mechanism. If the comparison is consistent, an identity authentication pass result is generated and bound to the current connection identifier. For ordinary devices, the session key recovery process can begin after basic authentication is successful. However, when the receiving device is pre-marked as a critical device, enhanced authentication is performed. Both the initiating and receiving devices generate temporary private keys locally and perform scalar multiplication based on a pre-selected base point to obtain the corresponding temporary public key. Subsequently, the two parties exchange temporary public keys through the established handshake channel and continue to perform scalar multiplication using their own temporary private key and the other party's temporary public key, thereby obtaining a consistent temporary shared key without directly exposing the local temporary private key. The temporary shared key is then combined with the encrypted session key fragment in the connection completion packet to generate the session key actually used in this connection. The session key is written to a protected session key cache, which can only be accessed by the current connection identifier, the current device pair, and the current permission context, preventing the key negotiated in one connection from being reused by other connections. For example, the basic authentication phase can be controlled within 200 milliseconds; critical devices can use the ECC-256 simplified parameter curve to perform temporary key exchange; the data encryption phase uses the AES-128 symmetric encryption algorithm and can adopt a counter mode that supports parallel processing and does not require padding, so that the data to be transmitted can be encrypted in parallel after being divided into multiple data fragments; the session key can be dynamically updated according to a fixed validity period, for example, after 30 minutes, both parties can renegotiate a new key based on the current connection identifier to replace the original key, thereby reducing the risk of long-term key exposure. The initiating device encrypts the data to be transmitted based on the session key, obtaining encrypted data. After each encrypted data fragment is formed, it calculates a CRC-32 cyclic redundancy check code and appends the check code to the end of the corresponding encrypted data fragment or to the check field before sending it. After receiving the encrypted data, the receiving device verifies the fragment integrity based on the appended CRC code. If the verification matches, it continues to use the same session key for decryption and reassembly. If the verification does not match, it is determined that an error occurred during microwave transmission or relay forwarding, and the fragment is re-acquired from the original sender or a cooperating node holding a copy of the fragment based on the intelligent fragmentation and cooperative anti-interference strategy.
[0044] In one embodiment, such as Figure 6 As shown, step S40 specifically includes the following steps: S41: Compare the operation type recorded in the permission request summary in the connection completion packet with the permission range pre-configured for the initiating device to obtain the permission verification result. The permission verification result includes a legal result where the operation type is within the permission range and an unauthorized result where the operation type exceeds the permission range. S42: When the permission verification result is valid, the soft bus connection corresponding to the connection completion packet is allowed to continue transmitting encrypted data under the soft bus connection; S43: When the permission verification result is an unauthorized result, the soft bus connection corresponding to the connection completion packet is frozen, the soft bus connection is disconnected, and a security alarm event is published through the distributed event bus.
[0045] In this embodiment, the permission request digest is parsed from the connection completion packet, and the operation type, operation object, permission level, initiator device identifier, and digest integrity flag recorded therein are written into the current soft bus connection context. Then, based on the initiator device identifier, the pre-configured permission range is read from the local permission configuration table, and the operation type is uniformly converted into a permission enumeration that can be recognized internally by the system to avoid misjudgment due to differences in field names, encoding formats, or capitalization of the same operation. During the comparison process, it is determined whether the operation type is within the permission range, and the permission range is simultaneously verified to be still valid, whether it is bound to the identity authentication pass result, whether it is consistent with the current connection identifier, and whether the permission request digest has been tampered with during transmission. If the operation type is within the authorized range and the digest verification, device identity, and connection context are all consistent, a valid result is generated. If the operation type exceeds the permission range, or the permission digest is missing, abnormal, the permission configuration is invalid, or the device identity and permission configuration do not match, an unauthorized result is uniformly generated. If the permission verification result is valid, the receiving device marks the current connection identifier as open and synchronizes the open state to the soft bus connection management module, session key cache, and data transmission queue, enabling encrypted data to continue to be transmitted under this soft bus connection. At the same time, the receiving device is allowed to perform integrity verification, decryption, reconstruction, and service distribution on the encrypted data according to the recovered session key. In order to prevent the permission state from being bypassed after authentication, the open process not only keeps the connection open, but also uses "authentication passed, session key valid, and permission verification valid" as the admission conditions for data sending and receiving. Only when all three conditions are met can the data transmission queue be allowed to dequeue, and the receiving side service interface be allowed to perform the corresponding operation. Moreover, the permission verification result can still be used for quick review for each critical operation. If the authorization verification result is unauthorized, the receiving device immediately freezes the current connection identifier, stops receiving or forwarding encrypted data under that connection, clears the unprocessed data cache, revokes the session key access permission corresponding to the connection, notifies the relay node or cooperating device to stop providing forwarding services for the connection, and returns a connection freeze or authorization denial response to the initiating device. The soft bus connection management module disconnects the corresponding soft bus connection, releases the transmission window, retransmission queue, and path resources, preventing the unauthorized connection from continuing to occupy the microwave link or re-entering the service processing flow through the retransmission mechanism. Simultaneously, the receiving device publishes a security alarm event through the distributed event bus. The alarm event encapsulates the initiating device identifier, receiving device identifier, connection identifier, operation type, reason for unauthorized access, trigger time, and processing result, enabling the authorization management module, security audit module, and cooperating device to synchronously detect this abnormal state and further trigger blacklist updates, risk counting, secondary authentication, or manual auditing processes.
[0046] like Figure 7As shown in the embodiment of this application, the timing diagram for generating channel state awareness and cooperative anti-interference strategy illustrates the interaction process between the initiating device, the receiving device, the soft bus connection management module, and the cooperative device, including probe message interaction, channel state data generation, local pre-configured parameter table matching, cooperative device status acquisition, relay node screening, multi-hop transmission path configuration, and cooperative anti-interference strategy synchronization. The timing interaction process includes: Step S101, the initiating device sends a probe message carrying a transmission timestamp to the receiving device, enabling the receiving device to perform delay measurement and signal sampling on the current microwave channel; Step S102, the receiving device returns the reception timestamp and signal sampling results to the initiating device, allowing the initiating device to calculate the transmission delay of the microwave channel and obtain the signal-to-noise ratio and signal attenuation; Step S103, the initiating device reports the calculated transmission delay, signal-to-noise ratio, and signal attenuation to the soft bus connection management module; Step S104, the soft bus connection management module combines the transmission delay, signal-to-noise ratio, and signal attenuation into channel status data, determines the channel scenario level based on the channel status data, and matches the corresponding local pre-configured parameter table; Step S105, the soft bus connection management module requests device status data from the collaborative devices managed by the HarmonyOS distributed soft bus, the device status data including signal reception strength, remaining battery power, and processor load; Step S106 In step S107, the soft bus connection management module calculates the relay score and constructs a link quality matrix based on the device status data of each collaborative device. When the signal-to-noise ratio is lower than a preset interference threshold, the collaborative device with the highest relay score is selected as the relay node, and a collaborative anti-interference strategy is generated. In step S108, the soft bus connection management module configures a multi-hop transmission path for the selected collaborative device, enabling data between the initiating device and the receiving device to be forwarded via the relay node. In step S109, the soft bus connection management module synchronizes the local pre-configured parameter table and collaborative anti-interference strategy with the initiating device, enabling the initiating device to initiate a soft bus connection according to the corresponding handshake parameters and transmission path. In step S110, the soft bus connection management module synchronizes the local pre-configured parameter table and collaborative anti-interference strategy with the receiving device, enabling the receiving device to receive the soft bus connection according to the same handshake parameters and transmission path as the initiating device.
[0047] like Figure 8As shown in the embodiment of this application, the three-round handshake and session key establishment timing diagram illustrates the interaction process between the initiating device, HarmonyOS distributed soft bus, the receiving device, and local secure storage, including connection request packet sending, simplified identity credential verification, response confirmation packet return, lightweight digital signature verification, connection completion packet sending, temporary public key exchange of key devices, and session key generation. The timing interaction process includes: Step S201, the initiating device, according to the handshake packet fields configured in the local pre-configured parameter table, encapsulates the device identifier of the initiating device, the local pre-configured parameter table summary, and the simplified identity credential into a connection request packet; Step S202, the initiating device sends the connection request packet to the HarmonyOS distributed soft bus; Step S203, the HarmonyOS distributed soft bus forwards the connection request packet to the receiving device, completing the first round of interaction in the three-round handshake; Step S204, the receiving device, according to the initiating device identifier in the connection request packet, reads the corresponding pre-shared key and local verification information from the local secure storage; Step S205, the local secure storage returns the identity credential verification result obtained based on the pre-shared key to the receiving device; Step S206, the receiving device verifies the simplified identity credential according to the identity credential verification result, and after successful verification, encapsulates the device identifier of the receiving device, parameter confirmation information, and lightweight digital signature into a response confirmation packet; Step S207, the receiving device sends the response confirmation packet to the HarmonyOS distributed soft bus. Step S208: The HarmonyOS distributed soft bus forwards the response confirmation packet to the initiating device, completing the second round of interaction in the three-round handshake. Step S209: The initiating device verifies the lightweight digital signature and parameter confirmation information in the response confirmation packet. After successful verification, it encapsulates the encrypted session key fragment and permission request digest into a connection completion packet. Step S210: The initiating device sends the connection completion packet to the HarmonyOS distributed soft bus. Step S211: The HarmonyOS distributed soft bus forwards the connection completion packet to the receiving device, completing the third round of interaction in the three-round handshake. Step S212: When the receiving device is a pre-marked critical device, the initiating device and the receiving device generate local temporary private keys and temporary public keys respectively, and exchange temporary public keys through the established handshake channel to calculate the same temporary shared key. Step S213: The receiving device verifies the legality of the encrypted session key fragment in the connection completion packet, and combines the temporary shared key with the encrypted session key fragment to generate the session key used for the current soft bus connection.
[0048] like Figure 9As shown in the embodiment of this application, the timing diagram of permission verification and soft bus connection control illustrates the interaction process between the initiating device, the receiving device, the permission configuration module, and the distributed event bus, including permission request summary sending, permission scope query, permission configuration return, permission legality comparison, legal connection release, encrypted data transmission, unauthorized connection freezing, and security alarm event publication. The timing interaction process includes: Step S301, the initiating device sends a permission request digest to the receiving device, the permission request digest including the operation type, operation object, and permission level requested by the initiating device; Step S302, the receiving device queries the permission configuration module for the permission range pre-configured for the initiating device based on the initiating device identifier; Step S303, the permission configuration module returns the corresponding permission configuration, permission validity period, and binding information between the permission configuration and the device identity and connection identifier to the receiving device; Step S304, the receiving device compares the operation type in the permission request digest with the pre-configured permission range, and verifies the integrity of the initiating device identity, current connection identifier, and permission request digest to obtain the permission verification result; Step S305, when the permission verification result is valid, the receiving device allows the current soft bus connection and returns the valid permission verification result to the initiating device; Step S306, under the allowed soft bus connection, the initiating device encrypts the data to be transmitted using the session key and sends a data packet with an appended cyclic redundancy check code to the receiving device. Encrypting data; Step S307: The receiving device performs integrity verification on the received encrypted data, and after successful verification, uses the session key to perform decryption, data reconstruction, and service distribution; Step S308: When the permission verification result is an unauthorized result, the receiving device returns a permission denial result to the initiating device, freezes and disconnects the corresponding soft bus connection; Step S309: The receiving device publishes a security alarm event through the distributed event bus, the security alarm event including the initiating device identifier, the receiving device identifier, the connection identifier, the operation type, the reason for unauthorized access, and the processing result; Step S310: The distributed event bus sends the security alarm event to the permission configuration module, enabling the permission configuration module to perform blacklist update, risk counting, or trigger secondary authentication based on the security alarm event; wherein, steps S305 to S307 correspond to the legal result branch executed when the permission verification result is a legal result, and steps S308 to S310 correspond to the unauthorized result branch executed when the permission verification result is an unauthorized result, the legal result branch and the unauthorized result branch are selected for execution according to the permission verification result.
[0049] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.
[0050] In one embodiment, a secure connection device based on the HarmonyOS distributed soft bus is provided, which corresponds one-to-one with the secure connection method based on the HarmonyOS distributed soft bus in the above embodiments. For example... Figure 10 As shown, the secure connection device based on HarmonyOS distributed soft bus includes: The data acquisition subsystem 701 is used to acquire channel status data of microwave channels and match the local pre-configured parameter table and cooperative anti-interference strategy of HarmonyOS distributed soft bus according to the channel status data. The handshake interaction subsystem 702 is used to perform a three-round handshake interaction between the initiating device and the receiving device based on the local pre-configured parameter table and the cooperative anti-interference strategy, and generate a connection completion packet. The data encryption subsystem 703 is used to authenticate the encrypted session key fragment in the connection completion packet, obtain the session key, and encrypt the data to be transmitted based on the session key to obtain encrypted data. The permission verification subsystem 704 is used to compare the permissions of the operation requested by the initiating device based on the permission request summary in the connection completion packet, obtain the permission verification result, and allow or freeze the soft bus connection corresponding to the connection completion packet based on the permission verification result.
[0051] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.
[0052] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0053] This application also provides a computer device, such as... Figure 11As shown, the computer device includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor. When the processor executes the computer program, it implements the steps in any of the above method embodiments, or when the processor executes the computer program, it implements the functions of each module / unit in the above device embodiments.
[0054] For example, the computer program may be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the computer device.
[0055] Those skilled in the art will understand that Figure 11 The computer device described is merely an example and does not constitute a limitation on the computer device. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device may also include input / output devices, network access devices, buses, etc.
[0056] The aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.
[0057] The memory can be an internal storage unit of the computer device, such as a hard drive or RAM. The memory can also be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory can include both internal and external storage units of the computer device.
[0058] This application also provides a readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the above-described method embodiments.
[0059] This application provides a computer program product that, when run on an electronic device, enables the electronic device to implement the steps described in the various method embodiments above.
[0060] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.
[0061] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0062] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0063] In the embodiments provided in this application, it should be understood that the disclosed apparatus / devices and methods can be implemented in other ways. For example, the apparatus / device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0064] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0065] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. 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 spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.
Claims
1. A secure connection method based on HarmonyOS distributed soft bus, characterized in that, include: Collect channel status data of microwave channels and match the local pre-configured parameter table of HarmonyOS distributed soft bus according to the channel status data; Based on the channel state data, link scoring and relay selection are performed on the collaborative devices managed by the HarmonyOS distributed soft bus to obtain a collaborative anti-interference strategy. Specifically, this includes: calculating the corresponding relay score based on the signal reception strength, remaining power, and processor load of the collaborative devices managed by the HarmonyOS distributed soft bus; constructing a link quality matrix between the collaborative devices based on the relay score; when the signal-to-noise ratio in the channel state data is lower than a preset interference threshold, selecting the collaborative device with the highest relay score from the link quality matrix as a relay node and generating a collaborative anti-interference strategy; the collaborative anti-interference strategy includes a relay node identifier, a multi-hop transmission path reconstructed from the original point-to-point transmission path between the initiating device and the receiving device based on the relay node, a collaborative topology structure matched according to the distribution mode of the collaborative devices, robust transmission parameters, retry control method, path backoff condition, and event response method. Based on the local pre-configured parameter table and the cooperative anti-interference strategy, the initiating device and the receiving device perform a three-round handshake interaction to generate a connection completion packet. The encrypted session key fragment in the connection completion packet is authenticated to obtain the session key, and the data to be transmitted is encrypted based on the session key to obtain encrypted data; Based on the permission request digest in the connection completion packet, the permissions of the operation requested by the initiating device are compared to obtain the permission verification result. Based on the permission verification result, the soft bus connection corresponding to the connection completion packet is allowed or frozen.
2. The secure connection method based on HarmonyOS distributed soft bus as described in claim 1, characterized in that, The acquisition of channel state data for the microwave channel includes: The transmission delay of the microwave channel is calculated based on the timestamp of the probe messages exchanged between the initiating device and the receiving device, and the received signal is demodulated based on the transmission delay to obtain the signal-to-noise ratio and signal attenuation of the microwave channel. The transmission delay, the signal-to-noise ratio, and the signal attenuation are combined to form the channel state data of the microwave channel.
3. The secure connection method based on HarmonyOS distributed soft bus as described in claim 1, characterized in that, The step of matching the local pre-configuration parameter table of HarmonyOS distributed soft bus based on the channel state data includes: The channel scene level is determined based on the transmission delay and signal-to-noise ratio in the channel state data. The channel scene level includes high bandwidth scene, medium bandwidth scene and low bandwidth scene. Based on the channel scenario level, the handshake packet field configuration, transmission rate, modulation method, channel bandwidth, maximum transmission unit, retry limit, acknowledgment timeout duration, transmission control window and sliding window packet quantity corresponding to the HarmonyOS distributed soft bus are matched to generate a local pre-configuration parameter table, and the local pre-configuration parameter table is written to the local storage medium.
4. The secure connection method based on HarmonyOS distributed soft bus as described in claim 1, characterized in that, When the signal-to-noise ratio in the channel state data is lower than a preset interference threshold, the cooperating device with the highest relay score is selected from the link quality matrix as a relay node, and a cooperative anti-interference strategy is generated, including: The signal-to-noise ratio in the channel state data is compared with a preset interference threshold; When the signal-to-noise ratio in the channel state data is lower than a preset interference threshold, the cooperative device with the highest relay score is selected as the relay node from the link quality matrix; Based on the relay node, the original point-to-point transmission path between the initiating device and the receiving device is reconstructed to obtain a multi-hop transmission path forwarded by the relay node. The collaborative topology is matched according to the distribution mode of the collaborative devices managed by the HarmonyOS distributed soft bus, and a collaborative anti-interference strategy is generated based on the multi-hop transmission path and the collaborative topology.
5. The secure connection method based on HarmonyOS distributed soft bus as described in claim 1, characterized in that, The step of performing a three-round handshake interaction between the initiating device and the receiving device based on the local pre-configured parameter table and the cooperative anti-interference strategy to generate a connection completion packet includes: Based on the handshake packet field configuration in the local pre-configured parameter table, the device identifier of the initiating device, the local pre-configured parameter table summary, and the simplified identity credential are encapsulated to obtain a connection request packet, and the connection request packet is sent to the receiving device. The receiving device compares and verifies the simplified identity credential based on the pre-shared key stored locally. After the comparison and verification are successful, the receiving device's device identifier, parameter confirmation information, and lightweight digital signature are encapsulated to obtain a response confirmation packet, which is then returned to the initiating device. The initiating device verifies the lightweight digital signature in the response confirmation packet. After the signature verification is successful, it encapsulates the encrypted session key fragment and the permission request digest to obtain a connection completion packet, and sends the connection completion packet to the receiving device.
6. The secure connection method based on HarmonyOS distributed soft bus as described in claim 5, characterized in that, During the handshake interaction, the signal-to-noise ratio continuously monitored by the collaborative anti-interference strategy is compared with a preset interference threshold; When the signal-to-noise ratio continuously monitored by the cooperative anti-interference strategy is lower than the preset interference threshold, a channel quality degradation event is triggered. According to the event response mapping table in the cooperative anti-interference strategy, the encapsulation parameters of the connection completion packet are switched to the corresponding robust transmission parameters to obtain the adjusted connection completion packet, and the adjusted connection completion packet is sent to the receiving device. The receiving device verifies the encrypted session key fragment and permission request digest in the received adjusted connection completion packet based on the locally stored verification information, and generates a verified connection completion packet.
7. The secure connection method based on HarmonyOS distributed soft bus as described in claim 1, characterized in that, The process involves authenticating the encrypted session key fragment in the connection completion packet to obtain a session key, and then encrypting the data to be transmitted based on the session key to obtain encrypted data, including: The simplified identity credentials of the initiating device are compared with the pre-shared key stored locally using hash digest. If the hash digests match, an identity authentication result is generated. When the receiving device is a pre-marked key device, scalar multiplication and exchange are performed on the local temporary private keys of the initiating device and the receiving device based on the pre-selected base point to obtain a temporary shared key. The temporary shared key is then combined with the encrypted session key fragment to obtain the session key. Based on the session key, the data to be transmitted is encrypted to obtain encrypted data, and a cyclic redundancy check (CRC) code for the encrypted data is calculated and appended to the encrypted data.
8. The secure connection method based on HarmonyOS distributed soft bus as described in claim 1, characterized in that, The step of comparing the permissions requested by the initiating device for the operation based on the permission request digest in the connection completion packet to obtain a permission verification result, and then allowing or freezing the soft bus connection corresponding to the connection completion packet based on the permission verification result, includes: The operation type recorded in the permission request summary in the connection completion packet is compared with the permission range pre-configured for the initiating device to obtain the permission verification result. The permission verification result includes a legal result where the operation type is within the permission range and an unauthorized result where the operation type exceeds the permission range. When the permission verification result is valid, the soft bus connection corresponding to the connection completion packet is allowed to continue transmitting the encrypted data under the soft bus connection. When the permission verification result is an unauthorized result, the soft bus connection corresponding to the connection completion packet is frozen, the soft bus connection is disconnected, and a security alarm event is published through the distributed event bus.
9. A secure connection device based on HarmonyOS distributed soft bus, characterized in that, The steps for implementing the secure connection method based on HarmonyOS distributed soft bus as described in any one of claims 1 to 8 include: The data acquisition subsystem is used to acquire channel state data of the microwave channel and match the channel state data with the local pre-configured parameter table of the HarmonyOS distributed soft bus. Based on the channel state data, it performs link scoring and relay selection on the collaborative devices managed by the HarmonyOS distributed soft bus to obtain a collaborative anti-interference strategy. Specifically, it includes: calculating the corresponding relay score based on the signal reception strength, remaining power, and processor load of the collaborative devices managed by the HarmonyOS distributed soft bus; constructing a link quality matrix between the collaborative devices based on the relay score; when the signal-to-noise ratio in the channel state data is lower than a preset interference threshold, selecting the collaborative device with the highest relay score from the link quality matrix as a relay node and generating a collaborative anti-interference strategy; the collaborative anti-interference strategy includes a relay node identifier, a multi-hop transmission path obtained by reconstructing the original point-to-point transmission path between the initiating device and the receiving device based on the relay node, a collaborative topology structure matched according to the distribution mode of the collaborative devices, robust transmission parameters, retry control mode, path backoff conditions, and event response mode. The handshake interaction subsystem is used to perform a three-round handshake interaction between the initiating device and the receiving device according to the local pre-configured parameter table and the cooperative anti-interference strategy, and generate a connection completion packet. The data encryption subsystem is used to authenticate the encrypted session key fragment in the connection completion packet to obtain the session key, and encrypt the data to be transmitted based on the session key to obtain encrypted data. The permission verification subsystem is used to compare the permissions of the operation requested by the initiating device based on the permission request digest in the connection completion packet, obtain the permission verification result, and allow or freeze the soft bus connection corresponding to the connection completion packet based on the permission verification result.
10. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the secure connection method based on HarmonyOS distributed soft bus as described in any one of claims 1 to 8.
11. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the secure connection method based on HarmonyOS distributed soft bus as described in any one of claims 1 to 8.
12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the secure connection method based on HarmonyOS distributed soft bus as described in any one of claims 1 to 8.