A cross-system trusted identity authentication and secure communication method based on a distributed soft bus

Abstract

The application discloses a cross-system trusted identity authentication and secure communication method based on a distributed soft bus, and relates to the technical fields of intelligent transportation and network security. The application limits authentication and scheduling within a preset geographical partition, and elects a temporary leading node in a time window, thereby significantly reducing consistency and broadcast range, avoiding network-level queuing and oscillation. In combination with weighted voting based on reputation and resources, the application preferentially selects stable and surplus nodes to bear authentication, and improves organization degree and fairness under high concurrency. The application introduces preloading and version binding of a hash tree identity digest, replaces whole-chain verification with path verification for first packet verification, and in a burst scenario, can move the calculation of a handshake key path and IO overhead forward and stabilize the propagation within a partition. When the digest is mismatched or suspicious, the application automatically falls back to complete certificate chain and revocation check, thereby guaranteeing real-time performance without sacrificing effectiveness.

Description

Technical Field

[0001] This invention relates to the fields of intelligent transportation and network security technology, and in particular to a cross-system trusted identity authentication and secure communication method based on a distributed soft bus. Background Technology

[0002] In high-density dynamic V2X scenarios, vehicles, roadside units (RSUs), and pedestrian terminals (such as smartphones and wearable devices) need to engage in frequent short-term interactions for vehicle-to-vehicle / vehicle-to-infrastructure (V2I) communication, blind spot warnings, and data sharing. Current engineering practices often employ certificate systems and message signing / encryption mechanisms based on Public Key Infrastructure (PKI), combined with protocols such as TLS / DTLS / EAP to establish secure channels. Meanwhile, some existing technologies introduce zero-trust architectures and blockchain technologies to alleviate cross-domain trust and identity federation issues.

[0003] V2X implementation involves multiple stakeholders and heterogeneous systems, including vehicle manufacturers / suppliers, roadside infrastructure operators, mobile networks and smart terminal platforms, etc. There are differences in trust anchors, policies and certificate lifecycle management between different domains.

[0004] While the above solutions can operate at normal density, in environments with dense equipment and highly transient connections, such as urban intersections and transportation hubs, frequent network access / switching leads to accumulated latency in handshakes, certificate verification, and revocation status checks (CRL / OCSP, etc.), making it difficult to reliably meet sub-second interaction requirements. Insufficient trust relationships, certificate mapping, and policy consistency between different PKI / policy systems affect the reliability of real-time messages from heterogeneous devices. Traffic light changes and sudden events trigger a large number of concurrent authentication / reconnection requests, and traditional batch authentication and general self-discovery protocols struggle to balance fairness and real-time performance, easily leading to queue accumulation and control plane congestion. Zero-trust continuous verification and high-frequency pseudonymous certificate rotation improve security, but increase signaling and computing power burdens under limited resources on the edge computing / wireless side. The confirmation latency and on-chain throughput limitations introduced by blockchain consensus and on-chain smart contracts under high churn (frequent joining / leaving) and sudden traffic make it difficult to directly meet the timeliness requirements of instantaneous authentication requests.

[0005] Therefore, there is an urgent need for a cross-domain trusted authentication and secure communication method for high-density dynamic V2X, which can reduce authentication and reconnection latency while ensuring mutual recognition and trust and privacy protection, and maintain stable throughput and fairness under authentication surges. Summary of the Invention

[0006] In view of the aforementioned existing problems, the present invention is proposed.

[0007] This invention provides a cross-system trusted identity authentication and secure communication method based on a distributed soft bus to solve the problems of high latency, congestion and complex policy coordination in high-density V2X cross-domain authentication, and large overhead of revocation, distribution and reconnection.

[0008] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0009] This invention provides a cross-system trusted identity authentication and secure communication method based on a distributed soft bus. The distributed soft bus is a software framework that supports device self-discovery, self-organizing networking, and multi-point to multi-point communication, including:

[0010] Step S1: The device connects to the distributed soft bus to perform self-discovery and self-organizing network, forming a dynamic network topology based on preset geographical partition units;

[0011] Step S2: When the device initiates a network access request, an identity authentication process is executed. The identity authentication process includes: prioritizing authentication requests based on device context information, and fast verification based on a preloaded identity digest packet.

[0012] Step S3: After successful authentication, a secure communication channel is established through temporary key negotiation based on elliptic curve cryptography.

[0013] Step S4: During the communication process, the session state and authentication traffic are dynamically managed based on the device behavior, and rollback verification and anomaly handling are implemented under the premise of meeting the security policy.

[0014] As a preferred embodiment of the cross-system trusted identity authentication and secure communication method based on a distributed soft bus described in this invention, the authentication request priority ordering in step S2 includes:

[0015] Requests are grouped according to geographical partitions, and a temporary dominant node is generated within each group using a time-window-limited election mechanism. The temporary dominant node coordinates the queue order and concurrency of authentication requests within that group.

[0016] As a preferred embodiment of the cross-system trusted identity authentication and secure communication method based on a distributed soft bus described in this invention, the election mechanism adopts weighted voting, with the weights determined jointly by the device reputation value and real-time resource availability. The device reputation value is generated based on historical authentication success rate, violation records, and certificate validity status, while real-time resource availability is estimated based on processor usage, available memory, and available bandwidth. The election is completed within a limited time window and includes automatic re-election in case the dominant node fails.

[0017] The weighted voting function is calculated as follows:

[0018] Step V1: A set of devices participating in the election is formed within the geographic partition unit, and a time window is set for sampling historical and real-time indicators. The election and necessary re-election are completed within this window.

[0019] Step V2, in the current window, for the device The voting value is defined as:

[0020] ,

[0021] in, Indicates device The number of votes, and The weighting coefficients are non-negative and , Indicates device The original reputation score. Indicates device The raw score of resource availability. This represents the set of devices participating in the election within the current group. This represents a small constant to prevent the denominator from being zero. The nonnegative coefficient representing the time decay rate, Indicates device The time interval between the most recent update of the indicator and the current time.

[0022] Step V3: The device reputation score is generated based on historical authentication success rate, violation records, and certificate validity status.

[0023] ,

[0024] in, Indicates device The original reputation score. Indicates devices within the window The authentication success rate Indicates device Violations of the suppression items, Indicates device Certificate validity status, Let represent the non-negative weighting coefficients of the three terms, and ;

[0025] Step V4, the resource availability generation rule is defined as a weighted aggregation of resource availability for processors, memory, and bandwidth:

[0026] ,

[0027] in, Indicates device The raw score of resource availability. Let represent the non-negative weighting coefficients of the three types of resources, and . , Indicates device Processor availability, This represents the normalized value of processor usage. Indicates memory availability. Indicates available memory. Indicates the memory reference value within the group. Indicates bandwidth availability. Indicates available bandwidth. Indicates the bandwidth reference value within the group;

[0028] Step V5, press Sort from highest to lowest, the highest-ranking node is selected as the temporary leader, and in case of a tie, the nodes are compared first. Compare again ;

[0029] Step V6: When the temporary dominant node fails or the window expires, a reselection is initiated, following the process of steps V1-V5.

[0030] As a preferred embodiment of the cross-system trusted identity authentication and secure communication method based on a distributed soft bus described in this invention, the preloaded identity digest packet adopts a hash tree structure, and the root hash is signed by a trusted root or cross-domain bridging entity and carries a revocation version number;

[0031] When a device joins the network, it receives the leaf node hash value and its verification path bound to its identifier. During authentication, it verifies the verification path and the root hash signature to achieve fast identity verification.

[0032] When the digest version does not match or verification fails, a fallback to the full certificate chain and revocation check is triggered.

[0033] As a preferred embodiment of the cross-system trusted identity authentication and secure communication method based on a distributed soft bus described in this invention, the rollback verification includes verifying the integrity of the certificate chain, the revocation list, or the online status, and updating the local identity digest packet after the verification passes; if the verification fails, network access is rejected and an audit entry is recorded.

[0034] As a preferred embodiment of the cross-system trusted identity authentication and secure communication method based on distributed soft bus described in this invention, the secure communication channel is established by one-time elliptic curve key exchange and binding the peer identity, negotiating to obtain a session master key, and generating a working key for encryption and integrity through a preset session key derivation function. The process supports session recovery and maintains forward confidentiality.

[0035] The session key derivation function is defined as follows:

[0036] Step K1: The shared secret is obtained by a one-time elliptic curve exchange, and the session master key is generated in a two-stage extraction-expansion process.

[0037] ,

[0038] ,

[0039] in, This represents the extracted master key material. This indicates a preset extraction salt; if pre-shared material exists, its hash is used; otherwise, a string of all zeros is used. This represents the shared secret obtained through a single elliptic curve swap. Indicates the session master key. and This represents extraction and labeled expansion functions based on the same hash family. Indicates the tagging context, Indicates the length of the output bytes;

[0040] Step K2: Within the same session, working keys for different purposes and transmission directions are derived using a unified format:

[0041] ,

[0042] in, Indicates the working key, superscript Indicates direction marker, take Send or Receive, subscript Indicates the purpose of the marker, take encryption, integrity or Initial vector, This represents an ASCII tag constant formed by concatenating the purpose and direction. Indicates byte-level connection, Indicates the length of the output bytes for the corresponding purpose;

[0043] Step K3, to bind identity, suite, and geographic partitioning elements, set:

[0044] ,

[0045] in, This refers to hash functions that belong to the same family as HKDF. Indicates the cipher suite identifier, and These represent the identity identifiers of the initiating party and the counterparty, respectively. Indicates geographic region identifier, This represents a summary of the handshake message transcription;

[0046] Step K4, derive according to usage order Once both parties have completed the same sequence derivation and the direction labels are consistent, they enter the application data stage.

[0047] Step K5: Use round-based indexing for stateless rotation. Once the data volume or time reaches a threshold, proceed to the next round.

[0048] ,

[0049] in, Indicates the first Round-robin master key, This indicates that the round index is encoded as a 32-bit unsigned integer byte string, when the record count... or rotation time Time to enter When resuming, both parties shall agree on the most recent common timeframe. Reconstruct the same round key.

[0050] As a preferred embodiment of the cross-system trusted identity authentication and secure communication method based on a distributed soft bus described in this invention, the dynamic management of session state includes:

[0051] Predict session lifecycle based on device movement speed, direction, and connection hold duration, and adjust key update frequency and session hold parameters accordingly. Trigger session migration or renegotiation in advance when a handover or disconnection trend is detected.

[0052] As a preferred embodiment of the cross-system trusted identity authentication and secure communication method based on a distributed soft bus described in this invention, the dynamic management of authentication traffic includes:

[0053] Within a group, token bucket throttling and priority queue scheduling are applied to authentication requests to prioritize the processing of urgent security-related requests. The maximum queuing delay threshold and exponential backoff strategy are combined to limit retry storms.

[0054] As a preferred embodiment of the cross-system trusted identity authentication and secure communication method based on a distributed soft bus described in this invention, the identity authentication process further includes adaptive encryption offloading.

[0055] When the local cryptographic computing load is detected to exceed the threshold, the offloadable signature verification or hash calculation will be assigned to a device or edge node with a trusted execution environment located in the same group.

[0056] The private key or master key is not disclosed during the uninstallation process, and the trustworthiness of the execution environment is verified through remote proof or equivalent proof mechanism.

[0057] As a preferred embodiment of the cross-system trusted identity authentication and secure communication method based on a distributed soft bus described in this invention, the method further includes anti-replay and privacy protection measures.

[0058] The authentication message carries a timestamp and a random number and is verified within the allowed clock deviation range. Audit logs are persisted within the group and are traceable. Only the geographic partition identifier is exposed to the outside world, not the precise location.

[0059] The beneficial effects of this invention are as follows: By limiting authentication and scheduling to a preset geographical partition and electing a temporary dominant node through a time window, this invention significantly reduces the consistency and broadcast range, avoiding network-wide queuing and oscillations. Combined with reputation- and resource-based weighted voting, it prioritizes stable nodes with sufficient capacity to handle authentication, improving organization and fairness under high concurrency. The invention introduces preloading and version binding of hash tree identity digests, allowing path verification to replace full-chain verification for first-packet verification. In sudden scenarios, the computation and IO overhead of the critical handshake path can be moved forward and stably propagated within the partition. When the digest mismatches or is suspicious, it automatically falls back to the complete certificate chain and revocation checks, ensuring both real-time performance and validity. It employs one-time elliptic curve key exchange and derives working keys for different purposes and directions using tagged HKDF, binding suites, identities, and geographical partition contexts to achieve forward secrecy and key space isolation in cross-system interconnection. For highly mobile links, it predicts session lifecycles based on speed, direction, and hold duration, triggering migration or renegotiation in advance to reduce latency jitter caused by handover. The authentication side implements token buckets and priority queues within the partition to limit retry storms and ensure that urgent security requests are prioritized. When local computing power is critical, TEE-controlled signature verification / hash offloading is enabled to smooth out peaks and valleys without leaking private keys.

[0060] In summary, this invention balances real-time performance, throughput, and privacy without relying on global consensus, and can stably support cross-system trusted identity authentication and secure communication in dense, transient vehicle network environments. Attached Figure Description

[0061] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation on the scope of this application.

[0062] Figure 1 This is a flowchart illustrating the cross-system trusted identity authentication and secure communication method based on a distributed soft bus in the embodiments. Detailed Implementation

[0063] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0064] All terms used in this application (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein should be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0065] For example, the terms “first” and “second” used in this application are only used to distinguish and describe similar objects, to differentiate the first object from another object, and are not used to describe a specific order or sequence, nor should they be interpreted as indicating or implying relative importance.

[0066] This application proposes a cross-system trusted identity authentication and secure communication method based on a distributed soft bus. The distributed soft bus is a software framework that supports device self-discovery, self-organizing networking, and multi-point to multi-point communication. The method includes:

[0067] Step S1: The device connects to the distributed soft bus to perform self-discovery and self-organizing network, forming a dynamic network topology based on the preset geographical partition units;

[0068] Step S2: When the device initiates a network access request, an identity authentication process is executed. The identity authentication process includes: prioritizing authentication requests based on device context information, and fast verification based on preloaded identity digest packets.

[0069] Step S3: After successful authentication, a secure communication channel is established through temporary key negotiation based on elliptic curve cryptography.

[0070] Step S4: During the communication process, the session state and authentication traffic are dynamically managed based on the device behavior, and rollback verification and anomaly handling are implemented under the premise of meeting the security policy.

[0071] In this embodiment, the distributed soft bus refers to a software framework that provides discovery, grouping, routing, and broadcasting capabilities. The geographical partitioning units of devices can be implemented using fixed-side-length grids or intersection-based area units. Location data is derived from satellite positioning, cellular data, or roadside beacon fusion. The dynamic network topology is jointly determined by the neighbor table and partition identifier. By default, the partition side length is approximately 100 meters, which can be adjusted between 50 and 200 meters according to road scale. The sampling period for device discovery is approximately 100 milliseconds, which can be adjusted between 50 and 200 milliseconds. The neighbor timeout determination is approximately 1.5 seconds, which can be adjusted between 0.5 and 3 seconds. The topology recalculation period is approximately 500 milliseconds, which can be adjusted between 200 and 1000 milliseconds, set according to empirical rules based on road density and vehicle speed. For example, a device enters or leaves a partition based on its center point crossing the boundary; crossing the boundary updates the partition identifier and triggers a lightweight notification. Optionally, when a high-precision location cannot be obtained, the roadside unit issues the current partition identifier to participate in subsequent processes. If necessary, such as if consecutive missing locations are found within a cycle or the neighbor table is empty, the cycle will continue to run based on the most recent valid partition and a forced recalculation will be performed in the next cycle to ensure feasibility and continuity.

[0072] In one embodiment, the authentication request priority sorting in step S2 includes:

[0073] Requests are grouped according to geographical partitions, and a temporary dominant node is generated within each group using a time-window-limited election mechanism. The temporary dominant node coordinates the queue order and concurrency of authentication requests within that group.

[0074] Specifically, the time-window-constrained election mechanism refers to aggregating metrics within a single partition using a short-time window to complete one election and necessary re-elections. The temporary dominant node is responsible for maintaining the authentication queue order and maximum concurrency within the partition. The default time window is approximately 200 milliseconds, configurable between 100 and 500 milliseconds; the default concurrency is approximately 8, tuned between 4 and 32 depending on processing capacity and link quality; the broadcast lifetime is limited to the current partition. Furthermore, requests within the same partition are queued in order of arrival time at the start of the window, and the temporary dominant node publishes the sorting and concurrency configuration at the end of the window. Optionally, if the metrics within the window are insufficient to achieve a stable sort, a degraded first-come-first-served configuration can be used to maintain order. If no announcement from the temporary dominant node is received within the specified confirmation time after the window ends, a re-election is immediately triggered, using the maximum concurrency of the previous window as a safety net.

[0075] In one embodiment, the election mechanism employs weighted voting, with the weights determined jointly by the device reputation value and real-time resource availability. The device reputation value is generated based on historical authentication success rate, violation records, and certificate validity status, while real-time resource availability is estimated based on processor usage, available memory, and available bandwidth. The election is completed within a limited time window and includes automatic re-election in case the dominant node fails.

[0076] The weighted voting function is calculated as follows:

[0077] Step V1: A set of devices participating in the election is formed within the geographic partition unit, and a time window is set for sampling historical and real-time indicators. The election and necessary re-election are completed within this window.

[0078] Step V2, in the current window, for the device The voting value is defined as:

[0079] ,

[0080] in, Indicates equipment The number of votes, and The weighting coefficients are non-negative and , Indicates equipment The original reputation score. Indicates equipment The raw score of resource availability. This represents the set of devices participating in the election within the current group. This represents a small constant to prevent the denominator from being zero. The nonnegative coefficient representing the time decay rate, Indicates equipment The time interval between the most recent update of the indicator and the current time.

[0081] Step V3: The device reputation score is generated based on historical authentication success rate, violation records, and certificate validity status.

[0082] ,

[0083] in, Indicates equipment The original reputation score. Indicates devices within the window Authentication success rate (range) ), Indicates equipment The violation suppression term (1 for no violation, converges to 0 as the severity of the violation increases). Indicates equipment The certificate validity status (1 for valid, 0 for revoked or invalid). Let represent the non-negative weighting coefficients of the three terms, and ;

[0084] Step V4, the resource availability generation rule is defined as a weighted aggregation of resource availability for processors, memory, and bandwidth:

[0085] ,

[0086] in, Indicates equipment The raw score of resource availability. Let represent the non-negative weighting coefficients of the three types of resources, and . , Indicates equipment Processor availability, This represents the normalized value of processor usage ( ), Indicates memory availability. Indicates available memory. Indicates the memory reference value within the group. Indicates bandwidth availability. Indicates available bandwidth. Indicates the bandwidth reference value within the group;

[0087] Step V5, press Sort from highest to lowest, the highest-ranking node is selected as the temporary leader, and in case of a tie, the nodes are compared first. Compare again ;

[0088] Step V6: When the temporary dominant node fails or the window expires, a reselection is initiated, following the process of steps V1-V5.

[0089] Specifically, normalization within the same geographical partition avoids bias caused by scale differences, and time decay is introduced to weaken the impact of expired metrics. The voting value consists of two parts: one part reflects historical stable performance and compliance status, and the other part reflects current capacity and processing capacity. The two are superimposed according to the strategy ratio, taking into account both stability and responsiveness. The reputation side consists of successful performance, violation suppression, and certificate status, which facilitates audit traceability. The resource side consists of the availability of processors, memory, and bandwidth, which facilitates rapid assessment of scheduling capabilities. The windowed calculation method and queue scheduling work together to maintain order under high concurrency. When paralleling, a hierarchical decision is adopted, and automatic reselection is performed when failure occurs. With the periodic update of the reference value, a stable dominant node selection logic can be maintained under different loads and topology changes.

[0090] For example, historical stability and compliance status are statistically derived from recent certification events within a window. The statistical sample can be taken from approximately 120 seconds or approximately 200 events. Violation suppression is mapped to a value between zero and one based on the number and severity of violations in a recent period. Certificate status is determined by a binary judgment given by local cache revocation or online status query. Processor usage on the resource side is taken from the moving average of local system counters, with a recommended averaging period of approximately 100 milliseconds. Memory availability is taken as the ratio of currently allocatable memory to the partition reference value and truncated to zero to one. Bandwidth availability is estimated from the link transmission margin in a recent period and is also truncated to zero to one. Time decay is represented by half-life, with a default half-life of approximately 3 seconds, which can be tuned between 1 and 5 seconds. To avoid the denominator being zero, a very small positive number is added to the normalized denominator, with a default magnitude of one millionth. Optionally, the reference value can be calculated from the median or percentile of the sliding window within the partition to enhance robustness in the presence of outliers. If necessary, if a metric is missing, it will be treated as zero and the source will be marked as incomplete in the announcement; if all metrics are missing, the node will not participate in the candidate list in this window.

[0091] In one embodiment, the preloaded identity digest packet adopts a hash tree structure, where the root hash is signed by a trusted root or cross-domain bridging entity and carries a revocation version number;

[0092] When a device joins the network, it receives the leaf node hash value bound to its identifier and its verification path (composed of the hash sequence of sibling nodes). During authentication, it verifies the verification path and the root hash signature to achieve fast identity verification.

[0093] When the digest version does not match or verification fails, a fallback to the full certificate chain and revocation check is triggered.

[0094] Similarly, the hash tree identity digest packet consists of a root signature, a revocation version number, leaf node hashes, and a verification path. The root signature originates from a valid signature chain of trusted roots or cross-domain bridging entities, and the verification path is a sibling hash sequence for verification. By default, the target size of the digest packet is controlled in the range of several kilobytes to adapt to the latency of vehicle broadcasting, and the version number increments synchronously with the update of revocation data. The digest packet update cycle is approximately 10 seconds by default, and can be adjusted between 5 and 30 seconds according to road density. To improve implementability, when a device first joins the network or crosses a partition, it prioritizes requesting the leaf node hashes and paths bound to its own identifier. The path length is limited by the device size and tree parameters in actual deployment, and generally does not exceed several dozen levels. Optionally, digest packets can be distributed within a partition using a combination of periodic broadcasting and on-demand resending. If necessary, such as root signature verification failure, incomplete path, or expired digest packet, the rollback verification process is immediately initiated and an audit event is recorded.

[0095] In one embodiment, rollback verification includes verifying the integrity of the certificate chain, the revocation list, or the online status, and updating the local identity digest packet after the verification passes; if the verification fails, network access is denied and an audit entry is recorded.

[0096] Optionally, certificate chain integrity verification prioritizes the local cache chain and revocation data. The acceptable freshness of revocation data is no more than approximately 1 hour by default, and the timeout for online status queries is no more than approximately 300 milliseconds by default. Upon successful verification, a digest packet is reconstructed and stored using the latest revocation version number. If verification fails, the corresponding identifier is blocked for a cooldown period, which is approximately 10 seconds by default, and exponential backoff is used to limit repeated network access attempts. When online queries are unavailable and local revocation data has expired, the system is only allowed to enter the isolation queue for further inspection in the least privilege mode, and no formal communication channel is granted.

[0097] In one embodiment, the establishment of a secure communication channel adopts a one-time elliptic curve key exchange and binds the peer's identity, negotiates to obtain a session master key, and generates a working key for encryption and integrity through a preset session key derivation function. The process supports session recovery and maintains forward confidentiality.

[0098] The session key derivation function is defined as follows:

[0099] Step K1: The shared secret is obtained by a one-time elliptic curve exchange, and the session master key is generated in two stages: extraction and expansion, for subsequent derivation.

[0100] ,

[0101] ,

[0102] in, This represents the extracted master key material. This indicates that salt is extracted (if there is pre-shared material, its hash is taken; otherwise, a string of all zeros is taken). This represents the shared secret obtained through a single elliptic curve swap. Indicates the session master key. and This represents extraction and labeled expansion functions based on the same hash family. Indicates the tagging context, Indicates the length of the output bytes;

[0103] Step K2: Within the same session, working keys for different purposes and transmission directions are derived using a unified format:

[0104] ,

[0105] in, Indicates the working key, superscript Indicates direction marker, take Send or Receive, subscript Indicates the purpose of the marker, take encryption, integrity or Initial vector, This represents an ASCII tag constant formed by concatenating the purpose and direction. Indicates byte-level connection, Indicates the length of the output bytes for the corresponding purpose;

[0106] Step K3, to bind elements such as identity, suite, and geographic region, sets:

[0107] ,

[0108] in, This refers to hash functions that belong to the same family as HKDF. Indicates the cipher suite identifier, and These represent the identity identifiers (including domain and public key fingerprint digests) of the initiating party and the peer party, respectively. Indicates geographic region identifier, This represents a summary of the handshake message transcription (including the hash of the negotiation parameters and the random number).

[0109] Step K4, derive according to usage order Once both parties have completed the same sequence derivation and the direction labels are consistent, they enter the application data stage.

[0110] Step K5: Use round-based indexing for stateless rotation. Once the data volume or time reaches a threshold, proceed to the next round.

[0111] ,

[0112] in, Indicates the first Round-robin master key, This indicates that the round index is encoded as a 32-bit unsigned integer byte string, when the record count... or rotation time Time to enter When resuming, both parties shall agree on the most recent common timeframe. Value reconstruction of the same round key;

[0113] Tags are defined using fixed ASCII phrases. and Match the key length of the selected algorithm. The required vector length for matching groups / AEAD; , and The results of the negotiation are given and written into the audit log;

[0114] Specifically, this section defines a derived system for elliptic curve one-time exchange. The idea is to aggregate the exchange output and optional salt in the extraction phase, and then generate working keys for different uses and directions in a labeled extension phase. The labeled context consists of a suite identifier, bilateral identity, geographic partition, and handshake transcription digest, thereby folding the protocol negotiation state and scenario constraints into short labeled inputs, which facilitates maintaining independent key spaces in multi-domain and cross-system environments. The general derived form achieves the separation of encryption, integrity, and vector through two-dimensional labels of purpose and direction, which can be directly mapped to common AEAD and message authentication schemes. The rotation part adopts a round index and threshold linkage method, which is linked to the amount of data and session duration, making it easy to update keys at a low cost in mobile scenarios or during load fluctuations.

[0115] Furthermore, the family of curves exchanged in a single transaction is negotiated and consistent with subsequent hash families. The output length of the master key material is consistent with the output length of the selected hash family. The tagged context is composed of a clearly defined suite identifier, party identifiers, geographic partition identifier, and handshake digest concatenated byte-by-byte and limited to a reasonable length to avoid excessively long inputs. The default data volume threshold is approximately one megabyte, and the time threshold is approximately 60 seconds; if either is reached, the next round of derivation begins. The lengths of the working key and initialization vector are consistent with the requirements of the selected encryption and integrity algorithm. Optionally, if session resumption is permitted, the working key for the same round is reconstructed based on the shared state of the previous round. If the handshake digest or tagged context comparison fails for either party, the process immediately aborts and reverts to renegotiation to ensure consistency and verifiability of the implementation.

[0116] In one embodiment, dynamically managing session state includes:

[0117] Predict session lifecycle based on device movement speed, direction, and connection retention duration, and adjust key update frequency and session retention parameters accordingly. Trigger session migration or renegotiation in advance when a handover or disconnection trend is detected.

[0118] In this embodiment, session lifecycle prediction uses a sliding window statistical analysis of recent speed and direction changes and hold duration. The output is the estimated remaining hold time, and the key update frequency and hold parameters are adjusted inversely with this time. The default sliding window is approximately 3 seconds, which can be tuned between 1 and 5 seconds. The early trigger threshold is set approximately 300 milliseconds earlier than the expected handover point by default, and can be adjusted between 200 and 500 milliseconds. If speed or direction changes are continuously observed to exceed a preset range, the key update frequency is increased and the hold time is shortened. Optionally, when the estimated hold time is extremely short, renegotiation is directly delayed until after the handover to reduce invalid handshakes. If necessary, such as missing motion parameters, the most recent valid estimate is used to maintain a window before degenerating to a fixed frequency update to ensure implementation even under edge conditions.

[0119] In one embodiment, dynamically managing authentication traffic includes:

[0120] Within a group, token bucket throttling and priority queue scheduling are applied to authentication requests to prioritize the processing of urgent security-related requests, while combining the maximum queuing delay threshold and exponential backoff strategy to limit retry storms;

[0121] Specifically, the token bucket rate-limits authentication requests at the granularity, with a default issuance rate of approximately 20 requests per second and a burst capacity of approximately 10 requests per second. This can be adjusted based on partition load, ranging from 10 to 50 requests per second and bursts from 5 to 20 requests per second. The maximum queuing latency threshold defaults to approximately 150 milliseconds; requests exceeding this threshold are discarded or downgraded. The initial wait time for exponential backoff defaults to approximately 200 milliseconds, with a multiplication factor of approximately 2, and a maximum wait time not exceeding approximately 2 seconds. Optionally, urgent security-related requests always occupy the highest priority queue and are not subject to backoff suppression but are limited by the maximum queuing latency. If necessary, and queue saturation persists, the temporary leading node reduces the concurrency limit and returns a congestion indication to the requesters to prevent authentication surges from spreading backward.

[0122] In one embodiment, the authentication process also includes adaptive cryptographic offloading:

[0123] When the local cryptographic computing load is detected to exceed the threshold, the offloadable signature verification or hash calculation will be assigned to a device or edge node with a trusted execution environment located in the same group.

[0124] During the uninstallation process, the private key or master key is not disclosed, and the trustworthiness of the execution environment is verified through remote proof or equivalent proof mechanism;

[0125] For example, adaptive cryptographic offloading only covers decryptable operations such as signature verification and hashing. The private key and session master key remain locally, and the offloading node must provide valid proof of a trusted execution environment. The default trigger conditions are: local processor usage continuously exceeding approximately 70% for at least approximately 500 milliseconds, network round-trip latency budget not exceeding approximately 50 milliseconds, and the default number of offloading tasks per batch not exceeding approximately 32. Optionally, offloading is immediately stopped and reverted to local execution when proof expires or verification fails; when network quality deterioration causes budget timeouts, unstarted offloading tasks are discarded and re-evaluated in the next window, ensuring a minimum executable caliber even under resource constraints.

[0126] In one embodiment, the method further includes replay protection and privacy protection measures:

[0127] The authentication message carries a timestamp and a random number and is verified within the allowed clock deviation range. Audit logs are persisted within the group and are traceable. Only the geographic partition identifier is exposed to the outside world, not the precise location, to reduce the risk of privacy leakage.

[0128] Similarly, the allowed deviation for timestamps defaults to no more than approximately 100 milliseconds and can be adjusted between 50 and 300 milliseconds; the random number length defaults to no less than approximately 96 bits and is guaranteed not to repeat within the session; audit logs include event time, peer identifier digest, partition identifier, and result code, and are persisted in a circular buffer with a default retention time of approximately 24 hours. Optionally, privacy protection adopts a method of only reporting partition identifiers and coarse time information, without outputting latitude, longitude, and precise time; if necessary, if a clock deviation is detected to exceed the allowed range and synchronization fails, authentication is rejected and a clock error indication is returned, and processing continues only after the time recovers to within the allowed deviation.

[0129] Finally, it should be noted that the above 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 or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0130] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are meant to be within the scope of this application and form different embodiments. For example, all the embodiments above can be used in any combination. The information disclosed in this background section is intended only to enhance the understanding of the general background of this application and should not be construed as an admission or in any way implying that such information constitutes prior art known to those skilled in the art.

Claims

1. A cross-system trusted identity authentication and secure communication method based on a distributed soft bus, wherein the distributed soft bus is a software framework supporting device self-discovery, self-organizing networking, and multi-point to multi-point communication, characterized in that... include: Step S1: The device connects to the distributed soft bus to perform self-discovery and self-organizing network, forming a dynamic network topology based on preset geographical partition units; Step S2: When the device initiates a network access request, an identity authentication process is executed. The identity authentication process includes: prioritizing authentication requests based on device context information, and fast verification based on a preloaded identity digest packet. Step S3: After successful authentication, a secure communication channel is established through temporary key negotiation based on elliptic curve cryptography. Step S4: During the communication process, the session state and authentication traffic are dynamically managed based on the device behavior, and rollback verification and anomaly handling are implemented under the premise of meeting the security policy. The authentication request priority ranking in step S2 includes: Requests are grouped according to geographical partitions, and a temporary dominant node is generated within each group using a time-window-limited election mechanism. The temporary dominant node coordinates the queue order and concurrency of authentication requests within that group. The preloaded identity digest packet adopts a hash tree structure, and the root hash is signed by a trusted root or cross-domain bridging entity and carries a revocation version number; When a device joins the network, it receives the leaf node hash value and its verification path bound to its identifier. During authentication, it verifies the verification path and the root hash signature to achieve fast identity verification. When the digest version does not match or verification fails, a fallback to the full certificate chain and revocation check is triggered.

2. The cross-system trusted identity authentication and secure communication method based on a distributed soft bus as described in claim 1, characterized in that, The election mechanism adopts weighted voting, with the weights determined by the device reputation value and real-time resource availability. The device reputation value is generated based on historical authentication success rate, violation records, and certificate validity status, while real-time resource availability is estimated based on processor usage, available memory, and available bandwidth. The election is completed within a limited time window and includes automatic re-election in case the dominant node fails. The weighted voting function is calculated as follows: Step V1: A set of devices participating in the election is formed within the geographic partition unit, and a time window is set for sampling historical and real-time indicators. The election and necessary re-election are completed within this window. Step V2, in the current window, for the device The voting value is defined as: ， in, Indicates device The number of votes, and The weighting coefficients are non-negative and , Indicates device The original reputation score. Indicates device The raw score of resource availability. This represents the set of devices participating in the election within the current group. This represents a small constant to prevent the denominator from being zero. The nonnegative coefficient representing the time decay rate, Indicates device The time interval between the most recent update of the indicator and the current time. Step V3: The device reputation score is generated based on historical authentication success rate, violation records, and certificate validity status. ， in, Indicates device The original reputation score. Indicates devices within the window The authentication success rate Indicates device Violations of the suppression items, Indicates device Certificate validity status, Let represent the non-negative weighting coefficients of the three terms, and ; Step V4, the resource availability generation rule is defined as a weighted aggregation of resource availability for processors, memory, and bandwidth: ， in, Indicates device The raw score of resource availability. Let represent the non-negative weighting coefficients of the three types of resources, and . , Indicates device Processor availability, This represents the normalized value of processor usage. Indicates memory availability. Indicates available memory. Indicates the memory reference value within the group. Indicates bandwidth availability. Indicates available bandwidth. Indicates the bandwidth reference value within the group; Step V5, press Sort from highest to lowest, the highest-ranking node is selected as the temporary leader, and in case of a tie, the nodes are compared first. Compare again ; Step V6: When the temporary dominant node fails or the window expires, a reselection is initiated, following the process of steps V1-V5.

3. The cross-system trusted identity authentication and secure communication method based on a distributed soft bus as described in claim 1, characterized in that, Rollback verification includes checking the integrity of the certificate chain, the revocation list, or the online status, and updating the local identity digest packet if the verification passes; if the verification fails, network access is denied and an audit entry is recorded.

4. The cross-system trusted identity authentication and secure communication method based on a distributed soft bus as described in claim 1, characterized in that, The establishment of the secure communication channel adopts a one-time elliptic curve key exchange and binds the peer's identity, negotiates to obtain the session master key, and generates working keys for encryption and integrity through a preset session key derivation function. The process supports session recovery and maintains forward confidentiality. The session key derivation function is defined as follows: Step K1: The shared secret is obtained by a one-time elliptic curve exchange, and the session master key is generated in a two-stage extraction-expansion process. ， ， in, This represents the extracted master key material. This indicates a preset extraction salt; if pre-shared material exists, its hash is used; otherwise, a string of all zeros is used. This represents the shared secret obtained through a single elliptic curve swap. Indicates the session master key. and This represents extraction and labeled expansion functions based on the same hash family. Indicates the tagging context, Indicates the length of the output bytes; Step K2: Within the same session, working keys for different purposes and transmission directions are derived using a unified format: ， in, Indicates the working key, superscript Indicates direction marker, take Send or Receive, subscript Indicates the purpose of the marker, take encryption, integrity or Initial vector, This represents an ASCII tag constant formed by concatenating the purpose and direction. Indicates byte-level connection, Indicates the length of the output bytes for the corresponding purpose; Step K3, to bind identity, suite, and geographic partitioning elements, set: ， in, This refers to hash functions that belong to the same family as HKDF. Indicates the cipher suite identifier, and These represent the identity identifiers of the initiating party and the counterparty, respectively. Indicates geographic region identifier, This represents a summary of the handshake message transcription; Step K4, derive according to usage order Once both parties have completed the same sequence derivation and the direction labels are consistent, they enter the application data stage. Step K5: Use round-based indexing for stateless rotation. Once the data volume or time reaches a threshold, proceed to the next round. ， in, Indicates the first Round-robin master key, This indicates that the round index is encoded as a 32-bit unsigned integer byte string, when the record count... or rotation time Time to enter When resuming, both parties shall agree on the most recent common timeframe. Reconstruct the same round key.

5. The cross-system trusted identity authentication and secure communication method based on a distributed soft bus as described in claim 1, characterized in that, The dynamic management of session state includes: Predict session lifecycle based on device movement speed, direction, and connection hold duration, and adjust key update frequency and session hold parameters accordingly. Trigger session migration or renegotiation in advance when a handover or disconnection trend is detected.

6. The cross-system trusted identity authentication and secure communication method based on a distributed soft bus as described in claim 1, characterized in that, Dynamic management of authentication traffic includes: Within a group, token bucket throttling and priority queue scheduling are applied to authentication requests to ensure the processing of urgent security-related requests. The maximum queuing delay threshold and exponential backoff strategy are combined to limit retry storms.

7. The cross-system trusted identity authentication and secure communication method based on a distributed soft bus as described in claim 1, characterized in that, The authentication process also includes adaptive encryption offloading: When the local cryptographic computing load is detected to exceed the threshold, the offloadable signature verification or hash calculation will be assigned to a device or edge node with a trusted execution environment located in the same group. The private key or master key is not disclosed during the uninstallation process, and the trustworthiness of the execution environment is verified through remote proof or equivalent proof mechanism.

8. The cross-system trusted identity authentication and secure communication method based on a distributed soft bus as described in claim 1, characterized in that, The method also includes replay protection and privacy protection measures: The authentication message carries a timestamp and a random number and is verified within the allowed clock deviation range. Audit logs are persisted within the group and are traceable. Only the geographic partition identifier is exposed to the outside world, not the precise location.

Images