Vehicle-mounted double-channel near distance mutual authentication method
By combining fine ranging via Wi-Fi with time coupling alignment via Bluetooth Low Energy, the problem of insufficient connection coverage and signal fluctuation in vehicle-mounted mutual authentication solutions under specific scenarios is solved. This enables auditable close-range mutual authentication and wireless anomaly detection on the server side, thereby improving the trusted mutual authentication capabilities between vehicle-mounted terminals.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- 郝彦博
- Filing Date
- 2026-03-16
- Publication Date
- 2026-06-05
AI Technical Summary
Existing vehicle-mounted mutual authentication solutions suffer from insufficient low-power Bluetooth link coverage in scenarios such as underground garages, factories, and charging stations, resulting in large fluctuations in signal quality. Furthermore, single close-range contact records are easily forged and exploited by gangs using mutual authentication, wireless relays, or simulators, failing to effectively identify wireless anomalies and establish an auditable close-range mutual authentication structure.
A switchable near-field witness structure is established by using fine ranging of WLAN and time coupling alignment of Bluetooth Low Energy. The wireless relay and abnormal forwarding are identified by multi-node witness topology on the server side. The robustness of near-field co-existence proof is improved by using dual-channel joint scoring, and the uploading of raw wireless data is avoided.
Balancing power consumption and compatibility across different scenarios, it improves the robustness and interpretability of near-field mutual authentication, identifies fixed small groups and templated mutual authentication paths, prevents witness isolation, and enhances the trusted mutual authentication capabilities between vehicle terminals.
Smart Images

Figure FT_1 
Figure FT_2 
Figure FT_3
Abstract
Description
Technical Field
[0001] This invention belongs to the field of vehicle-mounted trusted forensics and wireless anomaly detection, and particularly relates to a vehicle-mounted near-field mutual authentication and wireless anomaly detection method, system and storage medium based on Wi-Fi FTM / BLE time coupling alignment. Background Technology
[0002] Existing in-vehicle authentication solutions primarily rely on Bluetooth Low Energy (BLE) broadcasting and scanning to establish close-contact verification. However, in scenarios such as underground parking garages, factory areas, charging stations, high-density wireless environments, or environments with limited link coverage, a single BLE link can easily suffer from insufficient coverage, insufficient interaction time, or significant signal quality fluctuations. Furthermore, relying solely on a single close-contact record to determine credibility makes it vulnerable to exploitation by group authentication schemes, wireless repeaters, emulator reuse, or mass script forgery.
[0003] Other exposure notification solutions for public health exposure notification typically only establish probabilistic contact records around anonymous low-power Bluetooth broadcast contact windows. Their design goal is to provide large-scale low-power contact notifications, rather than forming an auditable close-range mutual verification structure by combining fine ranging time coupling of wireless LAN, challenge-response order, and server-side topology verification between controlled vehicle terminals.
[0004] While some existing solutions mention multi-terminal mutual authentication, they often remain at the level of "whether mutual authentication exists," failing to unify the modeling of two types of short-range links—Wi-Fi and Bluetooth Low Energy—nor to incorporate dual-channel temporal coupling relationships and witness topology anomalies into the long-term verification framework on the server side. Therefore, it is necessary to propose a dual-channel short-range mutual authentication solution that is engineering-featured on the terminal side, capable of long-term verification on the server side, and able to identify wireless relays, abnormal forwarding, and templated mutual authentication paths. Summary of the Invention
[0005] This invention provides a vehicle-mounted near-field authentication and wireless anomaly detection method, system, and storage medium based on fine ranging of wireless local area network and time coupling alignment of Bluetooth Low Energy, achieving the following objectives: 1. Establish a switchable and jointly scored near-field witness structure between Bluetooth Low Energy and Wi-Fi links; 2. Bind wireless observation results to device-side window summaries, monotonic counter references, and chained references to prevent witness isolation; 3. Identify wireless relays, anomalous forwarding, fixed small group reuse, and templated injection through server-side multi-node witness topology; 4. Improve the robustness and interpretability of near-field co-existence proofs without requiring the uploading of original sensitive wireless data.
[0006] This invention does not require either Wi-Fi or Bluetooth Low Energy to be the sole primary link in all scenarios. Instead, it allows switching between primary witness mode and dual-channel joint scoring mode according to rule version identifiers in different scenarios such as low power priority, underground parking garage, charging station, factory area, high-risk area or wireless environment restriction, thereby taking into account power consumption, compatibility and probative value in mass production.
[0007] Furthermore, in the main embodiment of the present invention, the peer for close-range mutual authentication can be another controlled vehicle-mounted terminal. This other controlled vehicle-mounted terminal is managed by the same implementing entity, which manages its underlying communication stack, device reference generation rules, and protected key materials. This enables it to output protected device identifier references, session pseudo-identifiers, or broadcast authentication digests during wireless LAN or Bluetooth Low Energy broadcasting, discovery, connection, and challenge response processes. Thus, the mutual authentication relationship of the present invention can be formed through close-range interaction between two controlled vehicle-mounted terminals.
[0008] To achieve the above objectives, the present invention adopts the following basic structure: 1. The vehicle-mounted terminal continuously generates device-side window summaries within the window; 2. Within the connection window, the vehicle-mounted terminal and another controlled vehicle-mounted terminal exchange device references, summary references, challenge random numbers, and wireless observation summaries via Bluetooth Low Energy, Wi-Fi, or a combination of both; 3. The server encodes the wireless observation summaries into a unified witness vector to determine the validity of close contact; 4. The server constructs a witness graph based on multi-window and multi-terminal witness relationships and performs collusion scoring according to the graph's structural features; 5. The server outputs the credibility level, supplementary evidence request, freeze pending review, risk escalation, or dispute review result.
[0009] Correspondingly, the system of the present invention includes an in-vehicle terminal, another controlled in-vehicle terminal, and a server. The in-vehicle terminal, the other controlled in-vehicle terminal, and the server are configured to collaboratively execute the above-described in-vehicle trusted verification method. Attached Figure Description
[0010] Figure 1 A schematic diagram of the overall structure for vehicle-mounted near-field mutual authentication and wireless anomaly detection, which aligns fine ranging of wireless LAN with time coupling of Bluetooth Low Energy.
[0011] Figure 2 This is a schematic diagram of the process for generating a dual-channel near-field witness window and a unified witness vector on the end side.
[0012] Figure 3 A schematic diagram of the process for constructing and analyzing the reverse crosstalk graph on the server side.
[0013] Figure 4 This is a schematic diagram of the process for tripartite collaborative witnessing, controlled disclosure of disputes, and manual review.
[0014] Figure 5 This diagram illustrates the process of offline caching, retransmission of receipts, and cross-version compatibility migration.
[0015] V. Terminology Explanation 1. Connection Window: Refers to the time interval during which effective interaction occurs via Bluetooth Low Energy, Wi-Fi, or a combination of both. 2. Wireless Observation Summary: Refers to the result of bucketing, summarizing, or referencing wireless observations. 3. Unified Witness Vector: Refers to the server verification input after uniformly encoding the observation features of Bluetooth Low Energy and Wi-Fi. 4. Witness Graph: Refers to the graph structure with terminals as nodes, mutual witness relationships as edges, and time windows and spatial constraints as edge attributes. 5. Collusion Risk Score: Refers to the risk score calculated by the server based on the degree of anomaly in the graph structure.
[0016] VI. System Structure like Figure 1 As shown, the system of this invention includes at least a vehicle-side in-vehicle terminal, another controlled in-vehicle terminal serving as the primary mutual authentication counterpart, an optional site-side access node, and server-side modules for receiving, generating unified witness vectors, constructing graphs, and risk scoring. The various sides do not independently determine proximity validity, but rather collaboratively verify the same window summary and the same witness relationship.
[0017] 6.1 Vehicle-mounted terminal The vehicle-mounted terminal includes at least: 1. Vehicle communication observation layer, used to collect vehicle operation events; 2. Short-range communication module, used to perform Bluetooth Low Energy and Wi-Fi interaction; 3. Processor, used for window digest generation and interaction flow control; 4. Memory, used to store window digests, wireless witness digests, and sealed records; 5. Security component, used to perform integrity protection and protected key operations.
[0018] In one embodiment, the vehicle communication observation layer may include at least one or more of the following: vehicle bus interface, in-vehicle Ethernet controller interface, gateway isolation domain observation interface, or vehicle on-chip system-on-a-chip bus observation interface. Therefore, the device-side window summary can originate from bus observation in aftermarket OBD mode, or from domain controller, gateway isolation domain, or on-chip bus observation in pre-installed integrated mode, without altering the technical core of this invention revolving around the generation of a basic witness edge for close-range mutual verification between a vehicle terminal and another controlled vehicle terminal.
[0019] 6.2 Primary mutual certificate counterpart The primary authentication peer is another controlled vehicle-mounted terminal, which includes at least a short-range communication module, a processor, and a memory, used to participate in device reference exchange, digest reference exchange, challenge response, and wireless observation digest generation within the connection window. In this invention, the authentication edge is formed solely by controlled short-range interaction between the vehicle-mounted terminal and another controlled vehicle-mounted terminal, and not by interaction on the client's mobile phone side.
[0020] 6.3 Server The server must include at least: 1. Receiving module, used to receive window digests and wireless witness digests; 2. Unified witness vector construction module, used to fuse Bluetooth Low Energy and WLAN observation results; 3. Close-range verification module, used to determine close-range validity and relay suspicion; 4. Graph construction module, used to maintain a multi-terminal, multi-window witness graph; 5. Collusion scoring module, used to output a gang risk score; 6. Disposal module, used to perform supplementary verification, demotion, freezing, or dispute review.
[0021] VII. Methods and Procedures 7.1 Generation of Device-Side Window Summary In some embodiments, the vehicle terminal collects vehicle bus events, device status summaries, and wireless interaction event summaries according to fixed time windows or event windows, and binds them with window references, counter references, and chain references to generate device-side window summaries.
[0022] The device-side window summary can be further bound to rule version references, specification version references, or witness strength level references so that the server can reconstruct the close contact validity and spectral scoring results according to the same version caliber.
[0023] 7.2 Dual-channel near-range mutual verification generation like Figure 2 As shown, in one embodiment, the device side first forms a device-side service window summary, then performs Bluetooth Low Energy and Wi-Fi observation, time-coupled recording and wireless summary generation respectively, and finally merges the relevant results into a unified witness input that can be uploaded.
[0024] In some embodiments, at least the following steps are performed within the connection window: 1. One terminal broadcasts or establishes a connection and sends a device reference and a digest reference; 2. The other terminal records the Bluetooth Low Energy or Wi-Fi observation results; 3. Both parties exchange challenge-response or near-range random number references; 4. Both parties respectively form a wireless witness digest and perform integrity protection; 5. The wireless witness digest is bound to the device-side window digest reference and then reported to the server.
[0025] In some embodiments, if the object of mutual authentication is another controlled vehicle terminal, the device reference can be a device identifier reference protected by a security component, a session pseudo-identifier derived according to the rule version, or a broadcast authentication digest, thereby avoiding the direct use of a long-term stable plaintext address as the sole trusted premise. The server can jointly verify the device reference with the challenge return order, connection window identifier, Bluetooth Low Energy or Wi-Fi dual-link observation results, and device-side window event timeline, rather than determining proximity validity based solely on a single identifier field.
[0026] In some embodiments, the following broadcast authentication binding method can be adopted: The sending vehicle terminal first constructs a combined digest of session_hint, window reference, and challenge_nonce according to deterministic rules, and then calls the security component to perform authentication operations on the combined digest to generate a broadcast authentication reference; the receiving vehicle terminal records the broadcast authentication reference or its verification result while recording the Wi-Fi broadcast visibility, Bluetooth Low Energy scan results, and challenge return order; the server can simultaneously check whether the broadcast authentication reference is compatible with the connection window reference, challenge return order reference, Bluetooth Low Energy or Wi-Fi latency digest, and device-side window event timeline during verification. With this design, even if the peer uses a fixed module MAC, the system's proof does not depend on a single plaintext address, but on the intra-session binding relationship and cross-link temporal coupling relationship.
[0027] In some embodiments, the wireless witness summary is also bound to an evidence identifier to ensure that the deterministic deduplication key remains unchanged during network outage retransmission, repeated retransmission, or cross-batch playback for the same connection window. The server can return an idempotent receipt for repeated reporting of the same evidence identifier and include the duplication rate in the spectrum anomaly features.
[0028] In some embodiments, the evidence identifier may not be randomly generated, but rather determined by deterministic serialization of one or more of the following: connection window reference, local reference, peer reference, challenge reference, window reference, and counter reference, in a preset field order, followed by digest computation. The server can enable the serialized version, missing field bitmap, and link mode identifier to participate in the digest, thus avoiding the generation of multiple semantically identical but key-valued records for the same window during link retries, network outage retransmissions, or cross-node forwarding. In this way, the system can reduce the risk of redundant edge expansion and collision-related merging at the graph layer without increasing the complexity of state maintenance at the endpoint.
[0029] 7.3 Construction of Unified Witness Vector In some embodiments, the server encodes one or more of the following fields into a uniform witness vector: 1. Barreled value of Bluetooth Low Energy (BLE) received signal strength; 2. Barreled value of Bluetooth Low Energy (BLE) connection duration; 3. Summary of Bluetooth Low Energy (BLE) multi-round challenge-response delay; 4. Barreled value of Wi-Fi received signal strength or signal-to-noise ratio (SNR); 5. Wi-Fi channel number or bandwidth level; 6. Wi-Fi access point identifier (API) reference or network identifier summary; 7. Summary of Wi-Fi channel state information or fine ranging delay summary; 8. Summary exchange completion status; 9. Challenge return order and timeline consistency results.
[0030] Furthermore, the unified witness vector not only represents the observation results of a single link in Bluetooth Low Energy or Wi-Fi, but also the joint self-consistency relationship between the two channels. This joint self-consistency relationship can be composed of at least one or more of the following: link mode identifier, cross-link temporal coupling relationship, interpretable range of the difference in strength between the two links, and the correspondence between the wireless interaction timeline and the device-side window event timeline. In this way, the server can distinguish between weak witnesses where "a single link is accidentally established" and strong witnesses where "the two channels support each other within the same window."
[0031] In some implementations, for fine-grained ranging delay summaries in wireless LANs, the terminal or server may not directly input the single round-trip delay value into the model. Instead, it may generate one or more of the following summaries based on multiple fine-grained ranging measurements within the same connection window: quantile interval summaries, jitter interval summaries, abnormal long-tail markers, or effective sample count summaries. These summaries are then bucketed or intervalized before being incorporated into a unified witness vector. This ensures that, even in environments with strong multipath reflections and significant spikes in individual measurements, the validity of near-range measurements can still be determined based on distribution characteristics rather than single-point extreme values. For terminal pairs exhibiting stable fine-grained ranging distributions across multiple consecutive windows, the server can enhance their near-range evidentiary strength. For windows with only a few occasional low-latency measurements but abnormally amplified jitter ranges or abnormally increased long-tail proportions, the server can increase their relay suspicion or classify them only as weak witnesses.
[0032] 7.4 Criteria for Establishing Close Contact In some embodiments, the server uses a combined threshold or weighted scoring method to determine the validity of close contact: 1. The original received signal strength value is not used as the sole basis; 2. A single delay measurement result is not used as the sole basis; 3. Switching between Bluetooth Low Energy main mode, Wi-Fi main mode, and dual-channel joint mode is allowed according to risk scenarios; 4. When the conclusions of two links reinforce each other, the probative value is increased; 5. When two links show obvious divergence, a downweighting or relay suspicion label is triggered.
[0033] Furthermore, in some embodiments, the server may not require all windows to simultaneously satisfy the dual-link condition of Bluetooth Low Energy and Wi-Fi, but instead make differentiated judgments based on the witness strength level: 1. At the basic level, either Bluetooth Low Energy or Wi-Fi link is allowed to independently reach the threshold to form a usable witness; 2. At the enhanced level, the other link is required to provide at least one auxiliary self-consistent feature; 3. At the high-risk level, both links are required to simultaneously meet stricter timeline and latency self-consistency constraints.
[0034] 7.5 Graph Construction and Collusion Scoring like Figure 3 As shown, after receiving the unified witness vector, the server can first perform idempotent deduplication and field validation, then construct graph edge relationships by vehicle, station and time period, and perform collusion scoring on highly repetitive, small group closed loop and abnormal short edge structures.
[0035] Furthermore, graph edges are not automatically generated from any mutual verification record. Instead, they are only registered as graph edges eligible for long-term scoring when the close contact validity of the corresponding connection window reaches the scenario-based threshold and the wireless interaction timeline is compatible with the device-side window event timeline. For windows with only weak evidence of a single link, broken temporal coupling, or obvious conflicts in the device-side event timeline, the server may retain the original record for subsequent supplementary verification or dispute review, but will not directly include them in the long-term graph structure.
[0036] In some embodiments, the server constructs the witness graph as follows: 1. Terminals are nodes; 2. Mutual authentication relationships are edges; 3. Each edge contains at least one or more of the following: time window reference, location grid reference, contact strength summary, bilateral signature status, and historical consistency score.
[0037] The server can calculate a collusion risk score based on the following graph structure characteristics: 1. Excessive edge repetition rate; 2. Overly dense fixed small group closed loops; 3. A large number of short edges appearing synchronously; 4. Abnormal contraction of spatial distribution; 5. Repetition of high-similarity temporal templates; 6. Abnormal coupling between retransmission rate and mutual verification rate.
[0038] In some implementations, the server can further calculate the local triangle closure rate, the temporal consistency of closed triangles, and the consistency of deduplication of evidence identifiers among closed edges. When three nodes repeatedly form highly similar closed triangles within a short period of time, and the evidence identifier construction field of the closed edges changes only in a few non-critical bits, the server can determine this as an abnormal closure enhancement signal, rather than simply increasing the credibility level based on "multi-sided mutual verification." Therefore, this invention not only utilizes graph structure to identify group mutual verification but also suppresses relay attacks or templated scripts that amplify the forgery of graph triangular structures through deterministic deduplication logic.
[0039] Graph scoring does not take "more mutual verification equals greater credibility" as a fixed premise. Instead, it further considers whether mutual verification is concentrated in a fixed small group, whether there is a lack of external high-reputation nodes, whether highly similar edge patterns recur across multiple time periods, and whether it is accompanied by an abnormally high rate of duplicate reporting. This structured scoring avoids misjudging high-frequency mutual verification within a group as high-credibility coexistence.
[0040] In some implementations, the server may also optionally receive external anchor edge references from controlled third-party service nodes, controlled event probe nodes, or other controlled high-reputation third-party nodes, and use them as external weighted edges in the graph. The function of these external weighted edges is limited to one or more of the following: first, breaking the structural closure caused by long-term mutual verification within a closed group; second, providing additional high-reputation interleaving references for specific windows; and third, triggering supplementary verification, freezing, or dispute review when the group's suspicions are high. These external weighted edges do not replace the close-range mutual verification subjects between vehicle terminals, nor do they generate the basic mutual verification edges in this invention independently, but only participate in graph interpretation on the server side as auxiliary weighting material.
[0041] In some implementations, the server may further perform compatibility checks based on the external anchor reference and the corresponding connection window's time window reference, location grid reference, event phase reference, or anomaly cause vector. When the check is compatible, the server may increase the sufficiency of supplementary evidence or the priority of review for the corresponding witness record; when the check is incompatible, the server may add an anomaly marker to the corresponding window, trigger a supplementary evidence request, or transfer the case to dispute review.
[0042] 7.6 Handling Logic like Figure 4 As shown, when the server introduces another controlled vehicle terminal material, site summary, external context summary, or manually reviewed material, a dispute review loop can be formed on the basis of controlled disclosure, and the original risk level can be adjusted or the original conclusion can be maintained based on the review conclusion.
[0043] In some embodiments, the server operates according to the following principles: 1. For single instances of missing mutual verification or degraded wireless quality, reduce weight instead of directly determining cheating; 2. For windows with insufficient close-range validity but continuous device sidechains, output a supplementary verification prompt; 3. For edge or node groups whose collusion risk scores exceed the threshold, freeze, restrict weighting, or transfer to dispute review; 4. Perform idempotent deduplication on witness summaries with duplicate evidence identification, and do not score repeatedly.
[0044] VIII. Extended Implementation Methods 8.1 Underground parking garage scene In the underground parking garage, two controlled vehicle terminals first establish a connection via Wi-Fi and exchange protected device references or broadcast authentication digests, then supplement the challenge response via Bluetooth Low Energy. The server determines the validity of the proximity connection based on Wi-Fi channel stability, broadcast authentication digest consistency, Bluetooth Low Energy short-term connection success rate, and timeline consistency.
[0045] 8.2 Charging Station Scenarios In charging scenarios, terminals can prioritize using Wi-Fi as the primary witness link and bind the charging event summary with the Wi-Fi witness summary. The server combines the charging event timeline and the Wi-Fi observation summary to enhance the probative value of this window.
[0046] 8.3 Group Mutual Verification Scenarios like Figure 5 As shown, in scenarios of offline caching, network recovery, and batch retransmission, the client can first cache the unified witness vector and its digest reference. After the server completes idempotent deduplication and graph recalculation according to the original version, it will return the corresponding receipt or re-certification request.
[0047] In some embodiments, if multiple terminals mutually verify each other only within a fixed small group over a long period of time, have highly repetitive edge relationships, and exhibit abnormally shrinking spatial distribution, the server marks them as a high-risk collusion group and performs a downgrade or freeze on their corresponding revenue settlement or trust level.
[0048] IX. Beneficial Effects The present invention has at least the following beneficial effects: 1. Introducing Wi-Fi as an independently established near-field mutual authentication link, extending the near-field mutual authentication coverage when relying solely on Bluetooth Low Energy; 2. Improving witness robustness in underground parking garages, factory areas, and charging scenarios through dual-channel joint scoring; 3. Identifying fixed groups, scripted mutual authentication, and repetitive reuse behaviors through witness graphs; 4. Avoiding the uploading of raw sensitive wireless data through summarization and controlled disclosure design; 5. Naturally compatible with existing device-side continuous evidence chains, counter citations, chained citations, and evidence identification structures.
[0049] 10. Expanding on Additional System Modules and Data Paths To ensure the stable implementation of this invention in basic mass-produced hardware and server cluster environments, the following further elaborates on the division of the end-side modules, the data flow within the connection window, the server aggregation process, and the linkage between graph scoring and processing.
[0050] In some implementations, in addition to the aforementioned vehicle bus interface, short-range communication module, processor, memory, and security components, the vehicle terminal may be further subdivided into: window scheduling module, digest serialization module, witness cache module, connection state management module, challenge interaction module, deduplication key pre-calculation module, and local quality tagging module. The window scheduling module is responsible for determining fixed-period windows, event-triggered windows, or hybrid windows; the digest serialization module is responsible for encoding multi-source fields from vehicle bus, device status, and near-field interactions in a deterministic order; the witness cache module is responsible for temporarily storing wireless observation digests that have not yet formed complete peer confirmations before and after connection establishment; the connection state management module is responsible for maintaining the states of Bluetooth Low Energy broadcasting, scanning, connection establishment, Wi-Fi discovery, Wi-Fi connection, link switching, and link coexistence; the challenge interaction module is responsible for challenge random number distribution, response timeout control, response order recording, and retry throttling; the deduplication key pre-computation module is responsible for deterministically encoding connection window identifiers, digest references, and counter references to form candidate inputs for evidence identifiers; and the local quality tagging module is responsible for writing phenomena such as limited auxiliary nodes, frequent link switching, sudden drops in signal strength, insufficient connection duration, and system scheduling delays into the quality bitmap or quality tags.
[0051] In some implementations, another controlled vehicle-mounted terminal can participate in short-range link interaction as the primary authentication peer. This other controlled vehicle-mounted terminal can provide a protected device reference, session pseudo-identifier, broadcast authentication digest, time reference, connection status digest, and environmental wireless observation digest within the connection window. The server can jointly verify this type of controlled peer output with the vehicle-mounted terminal's side window digest, challenge timing, and link switching path to improve the stability and anti-spoofing capability of the authentication results.
[0052] In some implementations, the system may optionally introduce an external context digest separate from the mutual authentication, used to supplement time references, charging station network context digests, environmental wireless congestion level digests, or station AP broadcast digests. The external context digest does not form the mutual authentication subject, nor does it replace the mutual authentication edge between vehicle terminals; it serves only as an additional reference for the server when interpreting the connection window environment, reviewing disputes, or attributing scenarios.
[0053] In some implementations, the server side can be divided into at least the following layers: receiving and access layer, idempotent deduplication layer, window merging layer, unified witness vector layer, connection credibility scoring layer, graph construction layer, graph risk scoring layer, rule version management layer, dispute review layer, and result distribution layer. The receiving and access layer is responsible for receiving reports from terminals, another controlled vehicle terminal, site nodes, or external context sources; the idempotent deduplication layer deduplicates according to evidence identifiers and generates receipts; the window merging layer merges vehicle digests, Bluetooth Low Energy digests, and Wi-Fi digests belonging to the same or adjacent time windows into candidate review objects; the unified witness vector layer converts wireless features into server computation inputs in a unified format; the connection credibility scoring layer is responsible for outputting scores for close contact validity, relay suspicion, and interaction integrity; the graph construction layer is responsible for registering witness events as graph edges; the graph risk scoring layer is responsible for outputting collusion risk scores based on local and global structural features; the rule version management layer is responsible for selecting the appropriate judgment criteria according to rule version reference, specification version reference, scenario category, and vehicle type; the dispute review layer is responsible for replaying part of the window calculation process in user appeal or external review scenarios; and the result distribution layer sends credibility levels, freeze suggestions, supplementary evidence requests, or risk escalation instructions to external consumer nodes.
[0054] XI. Organization and Coding Standards of Data Items and Fields in Vehicle Terminals To enhance the full disclosure of this invention, the device-side window summary, wireless witness summary, and graph edge field are further described below.
[0055] In some implementations, the device-side window digest may include at least one or more of the following fields: window reference, counter reference, chained reference, device_state_digest, vehicle_event_digest, ble_event_digest, wifi_event_digest, time_quality_ref, energy_state_ref, power_mode_ref, rule version reference, specification version reference, source_bitmap, quality_bitmap, and seal_state_ref. These fields can be encoded using deterministic serialization to avoid different digest values for the same logical content on different terminal versions. For raw messages from the vehicle bus, they can be first mapped to an event-type digest or a statistical digest before entering the window serialization process, instead of directly uploading the raw bus frame.
[0056] In some implementations, the wireless witness digest may include at least one or more of the following fields: connection window reference, local reference, peer reference, ble_rssi_bucket, ble_conn_duration_bucket, ble_adv_scan_pair_ref, ble_rtt_seq_ref, wifi_rssi_bucket, wifi_snr_bucket, wifi_channel_bucket, wifi_bandwidth_bucket, wifi_bssid_ref, wifi_ssid_digest, wifi_ftm_delay_ref, challenge reference, challenge return order reference, link_switch_ref, witness_quality_bitmap, and evidence identifier. For fields that can expose precise location or precise wireless fingerprints, only the bucketed value, digest value, or intra-domain reference value may be retained.
[0057] In some implementations, graph edge records may include at least: edge_id, partyA_ref, partyB_ref, time_bin_ref, space_bin_ref, strength_score_ref, dual_sign_state_ref, evidence_refs, repeat_count_ref, risk_mark_ref, quality_score_ref, external_anchor_ref, and edge_ver. To facilitate long-term maintenance and dispute reconstruction, graph edges do not directly record reversible identity plaintext, but instead use de-identified device references or domain-separated identifier digests.
[0058] In some implementations, if the terminal supports one or more of the following modes: Wi-Fi Aware, SoftAP, STA, fine ranging, or passive Beacon monitoring, the server can record the link mode used in the current connection window through mode_bitmap and switch different scoring sub-rules accordingly. For example, in passive monitoring mode, the server prioritizes broadcast timing and environmental stability; in fine ranging mode, the server prioritizes round-trip latency bandwidth; and in Bluetooth Low Energy master mode, the server prioritizes connection duration, challenge-response order, and broadcast scan correspondence.
[0059] 12. Connection Window State Machine and Link Switching Mechanism In some implementations, the connection window between an in-vehicle terminal and another controlled in-vehicle terminal can be described by the following states: IDLE, Bluetooth Low Energy_DISCOVERY, Bluetooth Low Energy_CONNECTED, WIFI_DISCOVERY, WIFI_CONNECTED, DUAL_ACTIVE, CHALLENGE_PENDING, WITNESS_SEALED, WITNESS_QUEUED, WITNESS_SENT, ACKED. The terminal records the sequence of state transitions and the triggering reasons to form a connection timeline summary. For windows with frequent switching, sudden increases in latency, or intermittent links, the probative value of the window is reduced by writing it into the quality bitmap, rather than directly deleting the window.
[0060] In some implementations, the handover between Bluetooth Low Energy (BLE) and Wi-Fi is not simply a matter of "if the former fails, the latter takes over." Instead, it can employ one of the following modes: First, BLE discovers first, followed by Wi-Fi; second, Wi-Fi establishes first, followed by a low-latency challenge with BLE; third, both are established simultaneously and jointly scored according to weighted rules; fourth, one link is established while the other only provides environmental auxiliary features. The server determines whether the handover window is a natural handover, a power-optimized handover, or an abnormal avoidance handover based on the link handover path and timing.
[0061] In some implementations, if the current wireless environment results in insufficient Bluetooth Low Energy (BLE) coverage, the vehicle terminal can proactively switch to Wi-Fi enhancement mode when it detects that the peer has not returned a BLE interaction for an extended period or that the BLE connection duration is significantly lower than the historical average. It will then only require the peer to return the minimum usable connection proof field. This design allows the invention to maintain high compatibility across various aftermarket OBD combinations, pre-installed integrated terminals, and vehicle manufacturer-customized systems.
[0062] In some implementations, to prevent attackers from frequently switching links via scripts to circumvent the server's single-link scorer, the server can incorporate the number of link switches, the distribution of switch intervals, the change in signal strength before and after a switch, and the sudden change in challenge return delay into the abnormal features within the connection window. If the same group of terminals repeatedly exhibits highly similar switch patterns in multiple windows, this can be used as enhanced input for the graph risk scoring.
[0063] XIII. Calculation of the validity of close contact and expansion of scoring factors In some implementations, the validity of close contact can be composed of multiple sub-scores, such as contact intensity sub-scores, interaction integrity sub-scores, timeline consistency sub-scores, environmental stability sub-scores, and dual-link mutual verification sub-scores. The server can determine the final score based on the scenario level using weighted summation, segmented thresholds, or decision tree rules. Each sub-score should be mappable back to a specific field or event, enabling the provision of a cause vector during dispute review.
[0064] The contact strength sub-score considers the following factors: whether the bucketed value of the Bluetooth Low Energy (BLE) received signal strength falls within a reasonable range; whether the Wi-Fi received signal strength or signal-to-noise ratio matches the level of environmental congestion; whether the fine ranging delay is within the acceptable range for the corresponding scenario; whether the connection duration meets the minimum threshold; and whether the strength difference between BLE and Wi-Fi is within an interpretable range. For fine ranging delay, the sub-score further examines the quantile intervals within the same window, jitter bandwidth, the proportion of abnormal long tails, and the stability between adjacent windows, rather than using the minimum or average delay as the sole criterion. For environments with strong multipath interference, such as underground parking garages, the requirements for single-instance strength fluctuations are relaxed, but the consistency requirements for multiple consecutive observations are increased.
[0065] The interaction integrity sub-score considers the following factors: whether the digest reference exchange is completed, whether the challenge-response is closed within the predetermined order, whether there is a broken link midway, whether there are duplicate challenge references, whether there are missing fields returned by the peer, and whether there is a long tail exceeding the normal scheduling delay. If there is only link establishment within the window without digest reference closure, it is recorded as a weak witness instead of a strong witness.
[0066] The self-consistent sub-score of the timeline takes into account the following factors: the order of Bluetooth Low Energy events, the order of Wi-Fi events, the order of challenge issuance and response, whether there is a conflict between the device event timeline and the wireless interaction timeline within the window, and whether the time quality on the vehicle side is sufficient to support the review of the current window. If the terminal time quality deteriorates, the server can appropriately relax the local time deviation, but the overall probative value must be reduced accordingly.
[0067] The environmental stability sub-score considers the following factors: whether the changes in the bucketed results of the received signal strength within adjacent windows are reasonable; whether there are short-term abnormal jumps in the wireless LAN channel; whether the restricted markers of auxiliary nodes match the missing interactions; and whether the site environment context is compatible with the current wireless observation results. For known environments such as charging stations, parking lots, and factory areas, location category parameters can be introduced to make the scoring more relevant to the scenario.
[0068] The dual-link mutual verification sub-score reflects the degree of mutual support between Bluetooth Low Energy (BLE) and Wi-Fi. For example, when BLE latency is good but the Wi-Fi environment is extremely unstable, the dual-link mutual verification sub-score should not give an overly high conclusion; conversely, when Wi-Fi fine ranging is good but BLE duration is slightly shorter, if the other fields are consistent, it can still maintain a medium-to-high level of probative value.
[0069] XIV. Deployment of Graph Modeling Methods and Collusion Identification Logic In some implementations, the witness graph can be maintained using a sliding time window. The server generates local graphs on a daily, weekly, monthly, or business cycle basis, and then merges these local graphs into the long-term global graph. This can be used to identify both short-term, explosive mutual verification anomalies and long-term, closed-loop behaviors of small, fixed groups.
[0070] In some implementations, node attributes, in addition to identity references, may also include reputation rating, historical stability score, dispute hit rate, average mutual verification frequency, frequency of access by external high-reputation nodes, duplicate reporting rate, link pattern distribution, and location diversity score. Edge attributes, in addition to the aforementioned fields, may also include edge lifetime, edge first occurrence time, edge most recent occurrence time, edge quality fluctuation index, and edge direction symmetry index.
[0071] In some implementations, the collusion risk score combines local and global structural features. Local structural features include small group closure rate, triangular structure density, edge repetition strength, temporal template similarity, and bidirectional signature skewness; global structural features include external connection richness, location diversity, heterogeneous node interpenetration rate, cross-cycle edge replacement rate, and reputation hierarchical distribution. If a group has very dense internal connections but almost no overlap with high-reputation external nodes, its collusion risk score should be significantly higher.
[0072] In some implementations, the server can also identify a "scripted mass mutual verification" pattern. This pattern often manifests as multiple nodes generating a large number of witness edges under approximately the same time difference, approximately the same signal strength bucket, approximately the same link switching template, and approximately the same challenge return order. For this type of pattern, the server does not directly delete all edges, but first reduces the overall weight, and then further distinguishes them based on the continuity of the device chain and the status of external high-reputation witnesses.
[0073] In some implementations, edges provided by roadside equipment, charging stations, maintenance sites, controlled third-party service nodes, controlled event probe nodes, or plant infrastructure nodes can serve as high-reputation anchor edges in the graph. The role of high-reputation anchor edges is not to replace ordinary terminal mutual authentication, but rather to break down the closed structure within the network, enabling servers to more easily distinguish between genuine co-existence and closed mutual authentication networks, and providing a higher-level structural reference for supplementary authentication, demotion, or dispute review when necessary.
[0074] XV. Dispute Review, Supplementary Evidence and Controlled Disclosure In some implementations, when an external consumer node requests a verification of the trustworthiness of a window or a group of terminals, the server can generate a dispute verification task. This task specifies at least the timeframe to be verified, the range of evidence identifiers involved, the range of fields to be disclosed, the challenge random number, and the target rule version. The vehicle-mounted terminal, another controlled vehicle-mounted terminal, or an external context source returns the necessary digest values, timeline references, link pattern references, and local event counts according to the principle of minimum disclosure.
[0075] In some implementations, controlled disclosure materials can be tiered by level. The basic level discloses only edge references, score summaries, and quality bitmaps; the enhanced level discloses connection window timeline jumps, local challenge sequence references, and link pattern distributions; the deep level discloses continuous segments of adjacent windows, archived sequence-related summaries, and local contextual references. Disclosures at different levels are bound by a challenge_nonce to prevent third parties from substituting review materials.
[0076] In some implementations, the supplementary verification logic applies not only to a single connection window but also to the graph level. For example, when the internal mutual verification of a node group is too dense and lacks external anchor edges, the server can require it to increase the interaction coverage of high-reputation infrastructure nodes, nodes in different locations, or nodes with different hardware tiers in subsequent business cycles. This expands "supplementary verification" from single-window verification to mid-term structural verification.
[0077] XVI. Typical Attack Paths and Protection Mechanisms Attack Path 1: Wireless Relay Attack. Attackers extend Bluetooth Low Energy or Wi-Fi links to non-near-field environments via remote bridging, attempting to forge co-location. This invention enhances identification capabilities through multi-round challenge-response timing, fine-grained ranging delay summaries, connection duration, self-consistency scoring, and dual-link cross-verification. Even if a single link fails to fully identify a relay, the combined scoring of dual links and timelines can significantly increase the suspicion of a relay.
[0078] Attack Path Two: Scripted Mass Verification. Attackers control multiple emulators or terminals to generate a large number of witnesses under a fixed template. To counter this, the server identifies scripted graph patterns using indicators such as edge duplication rate, template similarity, insufficient location diversity, missing external anchor edges, and abnormal coupling of duplicate reporting rates.
[0079] Attack Path 3: Auxiliary Node Restriction Avoidance. Attackers may use the excuse of restricted auxiliary nodes to create low-quality witnesses and then attempt to interpret the missing witnesses as a systemic issue. In response, this invention treats the restricted marker only as a quality correction factor, without automatically exempting it from the proximity validity requirement. If the same group continuously generates structurally consistent low-quality witnesses under the pretext of restrictions, it can still trigger an increase in graph risk.
[0080] Attack Path 4: Batch Replay After Network Disconnection. Attackers replay a large number of similar windows after a network disconnection, attempting to cover up the anomaly through idempotent deduplication and batch retransmission. In response, the server performs a joint check on evidence identifiers, connection window identifiers, link pattern distribution, and graph edge repetition rate. If it finds that the structural templates of the batch windows are abnormally consistent, it proceeds to dispute review or freeze.
[0081] Attack Path Five: Infrastructure Impersonation. Attackers impersonate high-reputation site nodes to provide false anchors. To counter this, the server binds the reputation of infrastructure nodes to device identity registration, key version, location stability, and long-term behavioral history, preventing ordinary terminals from impersonating high-reputation infrastructure nodes using simple fields.
[0082] XVII. Supplementary Information on Parameter Definitions, Rule Versions, and Deployment Implementation In some implementations, the server can maintain multiple sets of parameters according to rule versions, such as the boundaries of the Bluetooth Low Energy received signal strength bucket, the boundaries of the Wi-Fi signal-to-noise ratio bucket, the acceptable latency range for fine ranging, the connection duration threshold, the switching threshold between basic and enhanced levels, the risk stratification threshold, and the dispute review trigger threshold. Different parameter sets should work together with vehicle type, scenario type, hardware level, and time quality level to determine the final judgment criteria.
[0083] In some implementations, if the system is deployed in different provinces and cities, different site network environments, or different partner operator environments, the server can maintain different environmental correction parameters for the regional wireless environment. For example, in large underground parking garages, higher multipath fluctuation tolerance is allowed; in open sites, link latency and directional consistency are emphasized; in factory environments, high-frequency edges are allowed between equipment and fixed infrastructure, but this needs to be interpreted in conjunction with shift times, fixed lines, and location switching rhythms.
[0084] In some implementations, deployment can be categorized into basic, enhanced, and high-security versions. The basic version uses Bluetooth Low Energy as the core, with Wi-Fi used for opportunistic enhancements; the enhanced version enables fine-grained Wi-Fi ranging, site anchoring, and long-term analysis of the geographic structure; the high-security version further introduces more infrastructure nodes, refined rule versions, and a more frequent dispute review mechanism. All three deployment methods should maintain a unified framework for device-side window summaries, counter references, chain references, and evidence identification.
[0085] In some implementations, to facilitate subsequent auditing and upgrades, the server retains the scoring version, key factor summary, and result justification vector for each graph scoring result. This allows for the replay of historical partial graphs based on the original scoring version after subsequent rule version upgrades, explaining why a specific treatment conclusion was given to a particular group at a certain point in time.
[0086] Through the above structure, the server can form multi-scenario deployment paths based on dual-channel close-range mutual verification, graph-based long-term review, supplementary verification and controlled disclosure, and parameter version management.
[0087] 18. Implementation details of the rule engine and the method of generating scoring results In some implementations, the server rule engine can be organized in a layered manner. The first layer is the intra-window link quality check layer, responsible for determining whether a single connection window meets the basic availability conditions; the second layer is the inter-window continuity check layer, responsible for determining whether there are abrupt changes in the quality of close-range mutual authentication in adjacent windows; the third layer is the local graph structure layer, responsible for identifying small groups and templated mutual authentication; the fourth layer is the long-term graph evolution layer, responsible for identifying structural anomalies across days, weeks, or business cycles; and the fifth layer is the handling mapping layer, responsible for mapping the scoring results to trust levels, weighting ratios, supplementary authentication recommendations, or freeze actions. The output of any layer should retain an intermediate summary or cause field for subsequent review.
[0088] In some implementations, the intra-window link quality check layer may output at least the following metrics: link_basic_ok, link_mode_ref, ble_quality_score, wifi_quality_score, timeline_consistency_score, replay_suspicion_score, and relay_suspicion_score. The inter-window continuity check layer may output at least the following metrics: neighbor_strength_delta, neighbor_mode_switch_rate, neighbor_quality_drop_flag, and neighbor_pattern_similarity. The local graph structure layer may output clique_density, edge_repeat_ratio, peer_diversity_score, and anchor_presence_score. The long-term graph evolution layer may output long_term_repeat_index, weekly_group_stability, cross_site_diversity, and external_link_mix_ratio. The processing mapping layer then outputs results such as trust_level, degrade_level, supplement_level, freeze_flag, and review_flag based on the comprehensive score.
[0089] In some implementations, the server can map the scoring results to multiple trust levels, such as T0, T1, T2, T3, and T4. T0 indicates that only basic reception conditions are met but sufficient witnesses are lacking; T1 indicates the existence of a single available witness but of average quality; T2 indicates relatively stable dual-link or enhanced witnesses; T3 indicates high self-consistency and low graph risk with dual links; and T4 indicates, in addition to T3, the presence of high-reputation infrastructure anchors or long-term stable external interleaving relationships. External consumer nodes do not make binary decisions based on a single score, but rather select different handling strategies according to the trust level.
[0090] 19. Combined definition with location category, business category, and time period In some implementations, location categories may include at least underground parking garages, surface parking lots, charging stations, maintenance and repair facilities, high-traffic areas along roads, residential areas, and commercial areas. The server may use different parameter sets for different location categories. For example, in underground parking garages, the weights for Wi-Fi channel stability and environmental reflection tolerance may be appropriately increased; in open parking lots, the weights for Bluetooth Low Energy connection duration and latency consistency may be appropriately increased; in maintenance and repair facilities, higher-frequency mutual authentication with fixed infrastructure nodes is permitted, but stronger timeline correspondence and identity registration consistency are required.
[0091] In some implementations, the business categories may include at least insurance scoring, carbon credit measurement, charging behavior confirmation, maintenance attendance confirmation, dispute evidence collection, and high-risk risk control. For insurance scoring and carbon credit measurement, the server may place greater emphasis on long-term graph structure stability; for maintenance attendance confirmation, greater emphasis may be placed on the anchor edge of the site infrastructure and the integrity of short-term connections; for high-risk risk control, the requirement for simultaneous establishment of dual links and the sensitivity of graph risk thresholds may be increased.
[0092] In some implementations, time periods can also be used as scoring correction factors. For example, during low-traffic nighttime hours, node diversity is already low, and the server can appropriately reduce the requirement for external penetration rate; in peak-hour scenarios, if extremely closed small groups still mutually verify each other, their suspiciousness is actually higher. By jointly modeling location categories, business categories, and time periods, the engineering rationality of the graph scoring can be improved.
[0093] 20. Graph Edge Life Cycle and Historical Archiving In some implementations, each graph edge can have four lifecycle states: generation, growth, decay, and archiving. The generation state corresponds to the first discovery of a mutual evidence relationship; the growth state corresponds to the edge being effectively strengthened multiple times; the decay state corresponds to the edge not appearing for a long time or its quality declining; and the archiving state corresponds to the edge no longer participating in online scoring but retaining its historical evidentiary value. Through edge lifecycle management, the server can maintain the real-time nature of online scoring while also retaining the structural information needed for reviewing historical disputes.
[0094] In some implementations, if an edge appears repeatedly across multiple periods but is always limited to only a very few companion nodes and lacks external anchor edges, its lifecycle can be labeled as a "closed-growth edge." If an edge, although not frequently occurring across multiple periods, often appears alongside different external high-reputation nodes, its lifecycle can be labeled as an "open-interleaving edge." These labels can further enrich the interpretability of graph risks.
[0095] In some implementations, the side summary, key scoring factor summary, last risk level, scope of key evidence identifiers involved, and relevant version identifiers are retained during archiving, without having to retain all intermediate temporary calculated values. This controls server storage costs while also meeting subsequent reconstruction needs.
[0096] 21. Scalable processing for exceptionally large-scale scenarios In some implementations, if the system is deployed in an environment with millions of terminals, the server can adopt hierarchical aggregation and sharded graph management. The first layer shards the graph by region or business line; the second layer maintains the local graph within each shard; and the third layer aggregates high-risk edges, high-risk nodes, or high-risk groups into a global risk index. This approach can maintain the graph scoring capability while avoiding the computational pressure caused by global real-time recalculation.
[0097] In some implementations, for high-concurrency access, the idempotent deduplication layer and the graph construction layer are separated. The idempotent deduplication layer first ensures the consistency processing of the same evidence identifier, and then sends the normalized event stream to the graph construction layer. This avoids abnormal retransmissions from directly amplifying the number of graph edges, leading to scoring errors.
[0098] In some implementations, for ultra-large-scale node sets, the server can also allocate different graph maintenance frequencies based on recent active windows, recent risk change rates, and recent business value. High-value and high-risk nodes use higher refresh frequencies; low-value and long-term stable nodes can have their update frequencies appropriately reduced to save resources.
[0099] 22. Supplement to Production Testing, Integration Debugging, and Online Verification In some implementations, the basic availability capabilities of Bluetooth Low Energy and Wi-Fi, the link mode support matrix, digest serialization consistency, and evidence identifier construction rules can be verified at the factory. This verification focuses not on measuring absolute wireless strength in a specific environment, but on ensuring consistency in the generation of fields, mode switching, digest referencing, and quality bitmaps.
[0100] In some implementations, the system integration phase can utilize multiple scenario samples, such as power stations, underground garages, open parking lots, and factory areas, to jointly verify connection timing, link switching, graph structure, and supplementary verification procedures. Through integration, the impact of certain link environment limitations, latency deviations of certain wireless LAN chips, or differences in the implementation of certain low-power Bluetooth stacks on the unified witness vector can be identified in advance, and the corresponding correction rules can be solidified into the rule version reference.
[0101] In some implementations, after the system is officially launched, the server can maintain a cautious strategy for the map scoring results during the initial operation phase. For example, it can initially focus on reducing weights and supplementing evidence, and then increase the freezing and strong processing thresholds after long-term statistical stability. This can avoid widespread false negatives caused by excessively high thresholds when the new system has insufficient samples.
[0102] 23. Supplementary Explanation on Compatibility with Other Evidence Links In some implementations, this invention can be directly used in conjunction with continuous heartbeat chains, phase anchoring, controlled disclosure, versioned metering, and asynchronous review state machines. For existing systems, simply adding wireless LAN digest and unified witness vector related fields on the endpoint and adding a graph layer and dual-channel scoring layer on the server side allows for gradual integration of this invention without requiring a complete overhaul of the existing main evidence chain architecture.
[0103] In some implementations, if the system has not yet deployed all relevant evidence links, the dual-channel mutual verification and graph scoring modules of this invention can be used separately as an independent near-range trust enhancement layer. This approach allows for phased implementation under different deployment conditions, different business priorities, and different cost levels.
[0104] Furthermore, there are clear data continuity relationships among the unified witness vector, graph edge fields, risk scoring factors, and status outputs of this invention. Each type of summary generated on the endpoint can be traced back to a specific connection window, a specific device-side window, or a specific link event, and each result output by the server can also be traced back to the corresponding field set and rule version. Therefore, this invention not only has a complete system structure but also high interpretability and verifiability of results.
[0105] In some implementations, if subsequent external consumer nodes wish to output more granular risk stratification based on this invention, such as calculating trust levels by vehicle, driver, site, or period, corresponding aggregation results can be added to the server side without changing the basic structure of this invention. This extension does not change the core requirements of this invention, including end-side connection windows, unified witness vectors, graph edge records, and risk scoring closed loops.
[0106] Furthermore, this invention discloses a complete path from connection window formation, wireless digest generation, unified vector construction, graph modeling, collusion identification, supplementary evidence and dispute resolution to multi-scenario deployment. Even if different implementing entities differ in specific parameter settings, link mode selection, or deployment scale, as long as the above core structure is adopted, it can still be implemented within the technical framework of this invention.
[0107] 24. Supplementary Explanation on the Consistency of Field Organization and Implementation In some implementations, the window digest, wireless witness digest, unified witness vector, graph edge record, and risk handling result used in this invention all have clear data sources, deterministic field organization methods, and judgment criteria that can be reproduced on the server side. Therefore, this invention does not remain at the level of abstract "multi-link judgment" or "graph recognition" concepts, but rather provides a complete closed loop of end-side generation, server merging, risk calculation, and result distribution.
[0108] In some implementations, even if the specific link chip model, site network conditions, or regional environment are different, the core structure of the present invention can still be established as long as the terminal and server adhere to the same field encoding, rule version, and scoring interface.
[0109] 25. Supplement to Unified Witness Field Arrangement and Compressed Transmission In some implementations, to reduce end-side reporting overhead, the unified witness vector can be organized with a fixed-length header and optional extension segments. The fixed-length header includes at least vehicle_id_ref, window_id, evidence_id, ble_quality_level, wifi_quality_level, time_quality_level, graph_seed_ref, and witness_mode_bitmap; the extension segments can carry, as needed, AP count statistics, connection dwell time range, handshake result category, background scan coverage, abnormal handover count, and supplementary reference hash. Upon receiving the data, the server first parses the fixed-length header to complete the main process judgment, and then decides whether to expand the extension segments based on the risk level.
[0110] In some implementations, certain numerical fields in the unified witness vector can be represented by discretized buckets. For example, signal stability can be divided into five or eight levels, connection dwell time can be divided into multiple intervals, and scan coverage can be mapped to a predefined level. Discretization reduces bandwidth and storage costs and helps avoid caliber deviations caused by inconsistencies in the original measurement accuracy across different chips or operating systems.
[0111] In some implementations, the server maintains a mapping table between the original vector summary and the expanded interpretation fields. This ensures that during subsequent dispute review, the compressed summary results can be used quickly, while also allowing for tracing back to the original structured interpretation items when necessary. This mapping table can be bound to specification version references and rule version references to ensure explicit isolation of interpretation methods between different versions.
[0112] 26. Collaborative supplementation between the station side, the external context side, and the equipment side. In some implementations, if the external consumption scenario involves three types of nodes—an external context source, a vehicle-mounted terminal, and a facility—this invention can organize the materials from these three parties into an alignable time window. The external context side can provide summaries of auxiliary scan results, application interaction events, or location permission status; the facility side can provide summaries of AP broadcasts, authentication handshake records, or local clock references; and the vehicle-mounted terminal provides its own window summary and a reference to the main evidence chain. After the server completes unified alignment of the materials from the three parties, a higher-confidence close-range witness conclusion can be formed; however, the mutual witnessing edge between vehicle-mounted terminals is still only generated by controlled close-range interactions between the two vehicle-mounted terminals.
[0113] In some implementations, all three parties' materials are not required to be present simultaneously. If the external context cannot be uploaded stably due to system permission restrictions, a bilateral environment interpretation can be formed primarily by the device side and the site side; if the site side is temporarily unavailable, the device side can form a primary mutual authentication with another controlled vehicle terminal, and the server can complete the de-confidence interpretation using only the available context. This design helps improve the resilience of the invention in complex mass production environments.
[0114] In some implementations, the server outputs three types of fields for the three-party collaboration results: witness_alignment_level, missing_party_bitmap, and recovery_suggestion. The former characterizes the degree of collaboration, the latter indicates the missing party, and the latter indicates whether rescanning, retransmission, or manual review is required, thus enabling external consumer nodes to quickly understand the integrity of this near-field witnessing.
[0115] 27. Supplement to the Mechanism of Edge Aging and Risk Inheritance in Witness Graphs In some implementations, edge records in the graph do not permanently maintain equal weight. The server can process historical edges in three ways: time decay, business cycle decay, and risk event-driven decay. For edges that are stable in the long term and have no anomalies, their impact on immediate risks can be gradually reduced; for edges that have recently switched frequently, repeated intensively in a short period of time, or are associated with multiple abnormal nodes, higher weights are maintained.
[0116] In some implementations, node risk can also be inherited from historical graph relationships. For example, even if a vehicle has not directly triggered a high-risk event recently, but it continuously forms high-frequency, short-stay mutual verification relationships with confirmed abnormal nodes, the server can apply an observational risk inheritance score to that vehicle. This inheritance score may not immediately trigger a freeze, but it can increase the probability of supplementary verification and the frequency of graph recalculation.
[0117] In some implementations, the risk inheritance process is limited by the maximum propagation depth and the maximum propagation attenuation rate to avoid excessive diffusion in the spectrum that could lead to widespread false positives. By explicitly defining the propagation depth and attenuation boundaries in the rule version, this invention can maintain good prudence while preserving the spectrum recognition capability.
[0118] 28. Supplementary information on dispute appeals, controlled disclosures, and reviews In some implementations, when a business participant objects to the results of proximity witnessing, the server can disclose only necessary fields, such as window number, connection mode type, quality level, summary of side risk reasons, and relevant version identifier, through controlled disclosure, without directly exposing the full wireless environment details. This approach supports appeals while avoiding over-disclosure of the geographic graph.
[0119] In some implementations, the review phase may allow reviewers to view simplified trends of adjacent windows before and after the same disputed window, such as trends in Bluetooth Low Energy quality levels, the number of visible Wi-Fi access points (APs), connection switching frequency, and graph edge risks. Observing adjacent trends can help determine whether an anomaly is an isolated, occasional issue or part of a persistent conspiracy.
[0120] In some implementations, if the appeal conclusion changes the original risk level, the server will create a new audit record by changing the reason, participating review nodes, scope of cited materials, and adjusted handling recommendations, rather than overwriting the original judgment. This ensures that the map recognition results and the manual review results coexist in the long term and can be replayed.
[0121] 29. Long-term mass production operation and maintenance and cross-version portability supplementation In some implementations, when terminal firmware, external context applications, and site systems are upgraded, the server supports parallel parsing of two or even more versions. The old version continues to calculate the unified witness vector according to the old field definitions, while the new version calculates it according to the newly added fields and new rules. The server then outputs a version compatibility identifier during the transition period. This mechanism avoids disrupting the continuity of near-field witnessing during the upgrade process.
[0122] In some implementations, if a certain type of link capability is enhanced in a later version, such as adding more refined Wi-Fi handshake summaries or richer Bluetooth Low Energy broadcast classification fields, the server can incorporate it as an enhanced feature into the scoring model, but older versions of terminals are not required to immediately possess the same capability. The scoring model distinguishes terminal tiers through a capability_bitmap to achieve smooth migration.
[0123] In summary, this invention further discloses the field arrangement of the unified witness vector, the alignment method of the three-party collaborative materials, the graph edge aging and risk inheritance mechanism, the dispute-controlled disclosure process, and the cross-version migration strategy. Therefore, this invention can not only be stably implemented in the current mass production environment, but also support subsequent scale expansion and version evolution.
[0124] 30. Supplement to the temporal coupling rules in close-range realism determination In some implementations, when determining whether Bluetooth Low Energy and Wi-Fi constitute valid near-range mutual authentication, the server compares not only spatial correlation but also temporal coupling. This temporal coupling includes at least the order of scan start and end times versus handshake start and end times, the deviation range between the device-side window end time and the site-side observation time, and the ordering stability of multiple sub-events surrounding the same evidence identifier. If spatial characteristics are similar but the temporal order is significantly abnormal, the server may lower the near-range confidence level.
[0125] In some implementations, the temporal coupling rule can introduce derived fields such as early_arrival_flag, late_arrival_flag, sequence_break_level, and overlap_ratio. By combining and judging these derived fields, pseudo-near-range relationships caused by forwarding spoofing, pre-recorded playback, or off-site retransmission can be identified. This rule is particularly suitable for combating collusion that only imitates spatial behavior but does not actually occur in the temporal chain.
[0126] 31. Supplementing the system with combined site profiles, business profiles, and vehicle profiles. In some implementations, the server maintains site profiles, service profiles, and vehicle profiles separately. Site profiles include at least AP stability, common connection patterns, historical peak hours, and common noise distributions; service profiles include at least typical dwell times, typical handshake paths, and result usage timeliness; vehicle profiles include at least historical witness stability, common mutual verification object distributions, and anomaly records. Once the unified witness vector enters the server, it can work in conjunction with the three types of profiles to improve anomaly detection accuracy.
[0127] In some implementations, if a vehicle suddenly exhibits an extremely abnormal link combination under normal station and normal business hours, and neither the station profile nor the business profile supports this pattern, the server can classify it as a higher risk. If the anomaly mainly stems from recent overall AP disturbances at the station, the server can prioritize attributing the risk to environmental factors and reduce the intensity of individual interventions. Thus, this invention can create a more nuanced distinction between group environmental noise and individual anomalies.
[0128] 32. Edge Gateway Preprocessing and Central Map Recalculation Supplement In some implementations, if the system deployment is extremely large, connection window aggregation, preliminary deduplication, and lightweight quality scoring can be performed first at the edge gateway before the results are sent to the central server for global graph recalculation. The edge gateway does not directly perform the final collusion determination, but is only responsible for reducing data surges and standardizing field encoding. The central server then continues to handle the reconstruction of graph relationships across regions, periods, and nodes.
[0129] In some implementations, the edge gateway can also cache short-term hotspot node relationships to ensure near-real-time risk alerts during short-term network fluctuations. However, this cached relationship has a relatively short lifespan, and the final archived results are still based on recalculation by the central server. This design demonstrates that the present invention supports both centralized and edge-cloud collaborative implementations.
[0130] 33. Supplementary Explanation on the Combination of Technical Units In some implementations, technical units such as edge window formation, Bluetooth Low Energy digest, Wi-Fi digest, unified witness vector, graph edge recording, graph scoring, risk inheritance, dispute resolution, and cross-version migration can be combined. The data transfer relationships between these technical units have been gradually explained above, forming a complete processing structure for dual-channel mutual authentication, anti-spoofing graph construction, and risk layering.
[0131] 34. Supplementary Examples of Typical Implementation Processes In some implementations, the typical process may be as follows: After a vehicle enters the depot, the terminal first generates a device-side service summary within the first time window, while simultaneously listening to Bluetooth Low Energy broadcasts and recording the first set of near-field quality fields; then, within the second time window, the terminal completes a wireless LAN scan or handshake and forms the second set of quality fields; the server merges the two windows using `window_group_ref` to form a unified witness vector, and writes it into the local graph along with the edge records of other vehicles at the same site during the same period; if the vehicle only forms stable edges with normal nodes and the temporal coupling relationship is reasonable, the server outputs a low-risk result; if the vehicle repeatedly forms similar edge structures with multiple high-risk nodes within a very short time, the graph recalculation is triggered and the risk level is increased.
[0132] In some implementations, an external context-side process may also be involved: an external application or edge context source performs an auxiliary scan of the site AP and Bluetooth Low Energy broadcast, and uploads scan_digest_ref and app_time_ref to the server; the server aligns these with the unified witness vector of the vehicle terminal to verify whether the device-side window actually occurs in the corresponding site environment. If the external context-side conclusion is consistent with the device-side conclusion, the risk score is further reduced; if the external context-side conclusion is consistently missing or contradictory, the server increases the priority of supplementary verification.
[0133] 35. Supplementary Measures for Robust Handling in Complex Noise Environments In some implementations, underground spaces, areas with severe metal obstruction, areas with multiple access points (APs) causing interference, and areas with limited wireless environments can all lead to drastic fluctuations in Bluetooth Low Energy (BLE) and Wi-Fi quality. To address this, the server does not directly apply strong measures based on single-window results, but instead makes a comprehensive judgment based on the trends of adjacent windows, the stability of site profiles, and the historical stability of graph edges. If the overall environmental noise is high but individual relationships are stable, the environmental noise should be appropriately downweighted; if the overall environment is normal but individual windows frequently show abnormalities, the suspicion of individual collusion or forgery should be increased.
[0134] In some implementations, the terminal can also write a noise_hint_bitmap to indicate whether it is in a known interference scenario, such as an underground warehouse, a temporary hotspot area, or a maintenance and testing environment. The server can use this bitmap as a scoring aid, but should not rely solely on it to exempt high-risk edge structures from review. Thus, the present invention maintains a balance between noise absorption and security protection.
[0135] 36. Data archiving, historical playback, and long-term strategy optimization and supplementation In some implementations, the server hierarchically archives unified witness vectors, graph edge records, and dispute results that have undergone risk resolution. Short-term hot data is used for real-time graph recalculation, medium-term data is used for periodic rule correction, and long-term cold data is used for appeal playback and strategy evaluation. By hierarchically categorizing data into hot and cold data, storage and computing costs can be reduced without sacrificing long-term traceability.
[0136] In some implementations, long-term strategy optimization can fine-tune risk thresholds based on historical false positive rates, successful re-certification rates, collusion identification hit rates, site stability distribution, and vehicle profile drift. Threshold adjustments do not directly override historical standards; instead, they are released as references to new rule versions, retaining the ability to replay historical versions. This approach facilitates continuous optimization of the invention during long-term mass production operation while maintaining audit interpretability.
[0137] Furthermore, the server can establish typical pattern libraries for long-term stable normal edge relationships and long-term high-risk abnormal edge relationships, respectively, for subsequent rapid comparison and strategy correction. This pattern library does not replace real-time graph calculation, but serves as an auxiliary reference to improve batch review efficiency and reduce the cost of repetitive manual analysis.
Claims
1. A method for vehicle-mounted near-range mutual authentication and wireless anomaly detection based on fine ranging of wireless local area network and time coupling alignment of Bluetooth Low Energy, characterized in that, The method is executed collaboratively by an in-vehicle terminal, another controlled in-vehicle terminal, and a server. The in-vehicle terminal includes an in-vehicle communication observation layer, a short-range communication module, a processor, a memory, and a security component for providing protected keys. The in-vehicle communication observation layer includes at least one or more of the following: a vehicle bus interface, an in-vehicle Ethernet controller interface, a gateway isolation domain observation interface, or an in-vehicle system-on-a-chip bus observation interface. The method includes: the in-vehicle terminal acquiring vehicle operation events, device status summaries, and short-range communication event summaries within a preset time window; generating a device-side window summary; and binding the device-side window summary to at least one or more of the following: a window identifier, monotonic counter reference information, a preceding chain reference information, and a rule version identifier; within a preset connection window, the in-vehicle terminal and the other controlled in-vehicle terminal exchanging window references, device references, summary references, challenge random numbers, and wireless observation summaries via Bluetooth Low Energy and at least one short-range link in a wireless local area network. The device reference includes at least one of a protected device identifier reference, a session pseudo-identifier, or a broadcast authentication summary. The wireless observation summary... The observation summary should include at least one of Bluetooth Low Energy observation summary and Wi-Fi observation summary; the vehicle-mounted terminal and the other controlled vehicle-mounted terminal perform integrity protection on the wireless observation summary, and bind the wireless observation summary with the device-side window summary reference, connection window identifier, and idempotent identifier (evidence identifier) to form a wireless witness summary; the server encodes the Bluetooth Low Energy observation summary, the Wi-Fi observation summary, the device-side window summary, and the challenge-response sequence within the connection window into a unified witness vector, and determines the validity of close contact, suspicion of remote relay, or suspicion of simulation replay based on the unified witness vector; the server receives witness records formed by multiple terminals within multiple time windows, constructs a witness topology with terminals as nodes and mutual verification relationships as edges, and calculates an anomaly risk score based on topology anomaly characteristics; the server outputs the credibility level, supplementary evidence request, freeze pending review, restricted weighting, or risk escalation handling result based on the validity of close contact, the anomaly risk score, the continuity verification result of the device-side window summary, and the idempotent deduplication result.
2. A vehicle-mounted near-range authentication and wireless anomaly detection system based on fine ranging via Wi-Fi and time coupling alignment using Bluetooth Low Energy, characterized in that, The system includes an in-vehicle terminal, another controlled in-vehicle terminal, and a server; wherein the in-vehicle terminal includes an in-vehicle communication observation layer, a short-range communication module, a processor, a memory, and a security component; the server includes a receiving module, a unified witness vector construction module, a short-range verification module, a graph construction module, a collusion scoring module, and a processing module; the in-vehicle terminal, the other controlled in-vehicle terminal, and the server are configured to collaboratively execute the method of claim 1.
3. A computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the method of claim 1.
4. The method according to claim 1, wherein the wireless LAN observation digest includes at least one or more of the following: received signal strength (Bundled), signal-to-noise ratio (SNR) (Bundled), channel number, bandwidth level, access point identifier reference, network identifier digest, channel state information digest, fine ranging round-trip time (RTT) digest, protected device identifier reference, session pseudo-identifier, or broadcast authentication digest; the Bluetooth Low Energy (BLE) observation digest includes at least one or more of the following: received signal strength (Bundled), connection duration (Bundled), broadcast and scan correspondence, connection establishment time reference, broadcast authentication digest, or multi-round challenge-response delay digest; wherein the broadcast authentication digest is generated by a security component after authentication of a combined digest of session_hint, window reference, and challenge_nonce.
5. The method according to claim 1, wherein the server encodes the Bluetooth Low Energy observation digest and the Wi-Fi observation digest into a unified witness vector, and determines the witness strength level based on a joint threshold, weighted scoring, or scenario-based rules; wherein the unified witness vector further includes at least one or more of the following: link mode identifier, cross-link temporal coupling relationship, and correspondence with the device-side window event timeline, so that the unified witness vector not only represents the single-link observation result, but also represents the joint self-consistency between the two channels; wherein the scenario-based rules correspond at least to one or more of the following: underground parking garage scenario, charging scenario, factory area scenario, high-risk scenario, and low-battery scenario.
6. The method of claim 1, wherein when the Bluetooth Low Energy link is unavailable, the interaction coverage is insufficient, or the connection duration is insufficient, switching to the WLAN master witness mode is permitted; when the WLAN link is unavailable, switching to the Bluetooth Low Energy master witness mode is permitted; and when both links are available simultaneously, the server increases or decreases the proof power of the connection window based on the joint self-consistency of the two links.
7. The method according to claim 1, wherein the server performs joint consistency analysis on the Bluetooth Low Energy round-trip time sequence and the Wi-Fi fine ranging time sequence, and compares the consistency of channel stability, connection duration, challenge return order, broadcast authentication digest and device event timeline within the window to identify suspected remote bridging, wireless relay, batch scripting injection or simulator reuse; wherein the server simultaneously verifies the compatibility between the broadcast authentication digest and the connection window reference, challenge return order reference and device-side window event timeline.
8. The method according to claim 1, wherein each edge in the witness graph is bound to at least three of the following: time window reference, location grid reference, contact strength summary, bilateral signature status, historical consistency score, and device-side window summary reference; and the server registers the corresponding witness record as a graph edge only when the close contact validity of the corresponding connection window reaches the scenario threshold and its wireless interaction timeline is compatible with the device-side window event timeline; the server calculates a collusion risk score based on one or more of the following: edge repetition rate, fixed small group frequency, closed loop density, abnormal synchronization degree, spatial distribution shrinkage degree, repeated reporting rate, or edge reuse rate.
9. The method according to claim 1, wherein the wireless witness summary is further bound to an idempotent identifier (evidence identifier), a monotonic counter reference information and a connection window identifier, the server returns an idempotent receipt for repeatedly reported identical idempotent identifiers, and incorporates the duplication rate, edge reuse rate or abnormal retransmission rate into the graph risk score.
10. The method according to claim 1, wherein the server outputs the witness record in a controlled disclosure manner, outputting only the scoring result, weight result, cause vector, or high-risk edge reference, without outputting the complete node relationship plaintext; and when the collusion risk score exceeds the threshold, the server does not directly delete the corresponding witness record, but reduces its weight, triggers a supplementary evidence request, freezes the weight of the associated record, or transfers it to dispute review; wherein the server receives anchor edge references from controlled third-party service nodes, controlled event probe nodes, or other controlled high-reputation third-party nodes as supplementary consistency material, and performs compatibility checks based on one or more of the anchor edge references and the time window references, location grid references, event stage references, or abnormal cause vectors corresponding to the connection window, increasing the supplementary evidence sufficiency or review priority of the corresponding witness record when the check is compatible, and triggering an abnormal flag, supplementary evidence request, or dispute review when the check is incompatible, without replacing the close-range mutual evidence subject between the vehicle terminal and another controlled vehicle terminal.