A vehicle-mounted anti-hardware relay detection method

Abstract

The application discloses a vehicle-mounted anti-hardware relay detection method. A vehicle-mounted terminal generates a challenge frame object or a honeypot message object in a controlled session, injects a controlled challenge into a vehicle bus, collects a response delay digest, a forwarding jitter digest and a noise coupling digest, and forms a relay detection object. A server generates a relay suspicion, an observation or a rejection result according to the relay detection object and a historical time delay baseline, and outputs a freezing, a supplementary certificate or a dispute review result when the risk is high.

Description

Technical Field

[0001] This invention relates to the fields of bus physical layer delay summary extraction, honeypot message challenge, and relay spoofing identification, and particularly to an in-vehicle anti-hardware relay method, system, and storage medium based on bus delay challenge and honeypot detection. Background Technology

[0002] Existing vehicle-mounted anti-counterfeiting and authenticity verification solutions often focus on device identification verification, wireless short-range ranging, protocol signature verification, or passive bus eavesdropping. In scenarios involving high-value vehicle risk control, financial leasing, luxury car leasing, and bulk logistics supervision, attackers may also connect a hardware man-in-the-middle device between the OBD interface and the vehicle terminal to forward, cache, delay, or forge bus interaction results. For the aforementioned attacks implemented through physical plug-in adapter boards, hardware repeater boxes, delayed forwarding modules, and message filtering / modification boards, relying solely on static identification or wireless short-range results still presents the following problems: 1. Attackers can insert forwarding hardware into the OBD path, harness path, or before the local controller without altering the upper-layer device identifier; 2. Hardware repeater boxes can buffer, delay forwarding, conditionally replace, or suppress specific packets, making passive eavesdropping difficult to detect; 3. Wireless short-range ranging schemes mainly reflect the distance relationship between the terminal and user equipment, base station, or infrastructure, making it difficult to directly prove the absence of additional hardware forwarding in the bus link; 4. Without specially designed bus delay challenges and decoy messages, servers struggle to identify intermediate hardware that "forwards but does not respond exactly like the original bus link"; 5. Existing anti-relay research largely focuses on fine ranging in wireless channels such as RTT, UWB, Bluetooth, or wireless LAN, which is different from the detection problem of inserting hardware forwarding modules into the vehicle's physical bus link.

[0003] Furthermore, physical insertion relay attacks are highly covert. Attackers can cache, retime, conditionally forward, or even selectively process packets from terminals without compromising the service protocol format, or only target specific identifiers or load scenarios. This makes it difficult for traditional methods of detecting packet presence and signature integrity to detect whether an extra hardware segment has been added to the path, whether forwarding buffering has occurred, or whether conditional filtering logic exists.

[0004] Moreover, real-world attacks don't always crudely delay all packets by a fixed amount of time. Specialized relay hardware may differentiate based on packet type, bus load, inter-frame interval, or even specific challenge events, making simple single latency threshold detection ineffective. If the system relies solely on passive bus monitoring, even if minor latency anomalies are detected, it's difficult to determine whether they are caused by natural jitter, temporary congestion, controller scheduling discrepancies, or relay hardware issues.

[0005] Therefore, it is necessary to propose an anti-hardware relay scheme for vehicle physical bus links. By using bus latency challenges, honeypot messages, and multi-dimensional anomaly coupling analysis, the scheme can improve the ability to identify plug-in relay boards, transparent forwarding boxes, and conditional filtering modules. At the same time, it can clarify the technical boundaries between anti-relay schemes such as wireless short-range RTT, UWB, or fine ranging. Summary of the Invention

[0006] The purpose of this invention is to provide a vehicle-mounted anti-hardware relay method, system, and storage medium based on bus latency challenges and honeypot detection, so as to improve the anti-insertion, anti-forwarding, and dispute verification capabilities of vehicle-mounted bus link authenticity verification, and to form interpretable and auditable risk conclusions on the insertion of hardware forwarding or conditional screening behavior in the physical bus path without relying on wireless spatial distance measurement.

[0007] Technical solution

[0008] To achieve the above objectives, the present invention adopts the following technical solution: This invention is executed collaboratively by an in-vehicle terminal and a server. The server issues a bus challenge object to the in-vehicle terminal. This bus challenge object includes at least one or more of the following: challenge_seq_ref, challenge timing reference, message template reference, sampling window reference, timing_profile_ref, honey_frame_ref, policy_ver, and epoch_nonce. The in-vehicle terminal injects a controlled challenge into the vehicle bus or bus observation path based on the bus challenge object, and sends challenge frames or honeypot messages on a preset bus path. It collects one or more of the following: response delay summary, delay jitter summary, inter-frame interval summary, response missing summary, and abnormal rearrangement summary, generating a bus challenge response object. The in-vehicle terminal performs local integrity protection on the bus challenge response object and then reports it to the server. The server generates hardware relay risk results based on one or more of the following: latency offset results, jitter coupling results, honeypot message processing results, historical path baseline deviation results, and abnormal replay results. It then outputs one or more of the following: pass, observe, supplementary verification, rejection, or dispute review. The risk results are used to indicate whether there is plug-in forwarding or conditional filtering hardware in the vehicle physical bus link, rather than to determine the distance relationship between wireless short-range devices.

[0009] In some implementations, the vehicle terminal injects a controlled challenge into the vehicle bus or bus observation path based on the challenge frame object, and collects one or more of the following: response delay summary, forwarding jitter summary, message period coupling summary, and electromagnetic noise coupling summary, to form a relay detection object.

[0010] In some embodiments of the present invention, the bus challenge object may also include one or more of path_ref, retry_policy_ref, load_bucket_ref, honey_policy_ref, capture_scope_ref, timing_guard_ref, and frame_mix_ref. path_ref is used to specify the target bus path or subpath, load_bucket_ref is used to describe the current bus load level, honey_policy_ref is used to indicate the triggering method, ratio, and activation conditions of honeypot messages, and timing_guard_ref is used to constrain the time and security boundaries of challenge execution.

[0011] In some embodiments of this invention, the bus challenge response object does not upload the complete original bus stream. Instead, it generates a verifiable digest result around the challenge frame and honeypot message, such as minimum latency, average latency, tail latency, jitter bucketing, missing rate, out-of-order rate, inter-frame interval digest, and local anomaly sequence signature. This digest-based design controls communication and storage costs while retaining crucial information needed for risk assessment.

[0012] In some embodiments of the present invention, the server not only evaluates individual latency metrics, but also jointly considers the coupling patterns between different challenge frames. For example, if some frames perform normally under low load, exhibit a significant increase in jitter after hybrid honeypot packet injection, or if some honeypot packets are incorrectly forwarded, incorrectly filtered, or abnormally ordered, the risk score of the insertion relay can be significantly improved.

[0013] Beneficial effects

[0014] Compared with the prior art, the present invention has at least the following beneficial effects: 1. Improve the ability to identify physically inserted repeater boards through bus latency challenges and response sampling; 2. Improve the probability of detecting conditional filtering modules, buffer forwarding boxes, and abnormally rearranged links through honeypot message and anomaly coupling analysis; 3. Improve the interpretability and maintainability of mass production deployment through historical path baselines and layered handling; 4. Improve subsequent auditing capabilities through dispute review interfaces, controlled disclosure, and object-level traceability; 5. Avoid falling back to the technical scope of wireless short-range RTT or fine ranging by constructing an object chain around latency, jitter, missing response, out-of-order, and honeypot message handling of physical bus paths; 6. The main focus of this invention is the detection of inserted hardware forwarding or filtering in physical bus links, rather than focusing on the spatial distance measurement between mobile phones and devices. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the overall structure of a bus latency challenge and anti-hardware relay detection system according to one embodiment of the present invention.

[0017] Figure 2 This is a schematic diagram illustrating the process of generating challenge frame objects, honeypot message objects, and noise observation objects in one embodiment of the present invention.

[0018] Figure 3 This is a schematic diagram illustrating the process of forming response delay summary, honeypot response anomaly, and noise coupling summary in one embodiment of the present invention.

[0019] Figure 4 This is a schematic diagram of the server-side joint determination and hierarchical processing flow in one embodiment of the present invention.

[0020] Figure 5 This is a schematic diagram of the dispute review and controlled disclosure process in one embodiment of the present invention.

[0021] Terminology and Object Conventions In this document, `challenge_seq_ref` can represent a sequence of challenge frames, a transmission order template, or a reference thereof. `timing_profile_ref` can represent the time distribution of challenge frames, inter-frame interval templates, segmented delay templates, or sampling rhythm templates. `honey_frame_ref` can represent honeypot message templates, spurious target frame templates, anomaly handling trap templates, or combinations thereof. `path_ref` can represent OBD paths, CAN paths, LIN paths, local subbus paths, or combinations thereof.

[0022] In this document, "bus challenge response object" refers to a summary object formed around the execution results of challenge_seq_ref and honey_frame_ref, rather than the complete bus message. "Hardware relay risk result" refers to a risk assessment of the presence of plug-in hardware forwarding or conditional filtering modules in the bus physical path, not the spatial distance between the terminal and the user equipment.

[0023] System Structure like Figure 1 As shown, the system corresponding to this invention includes at least: 1. Bus challenge sending module, used to send challenge frames or honeypot messages; 2. Response sampling module, used to collect latency, inter-frame interval, and response-related summaries; 3. On-board terminal processor, used to construct bus challenge response objects; 4. Local timing correction module, used to perform local corrections for sampling baseline, clock error, and bus load effects; 5. Security component, used to perform local integrity protection; 6. Server-side risk assessment module, baseline module, rule management module, and audit module.

[0024] The challenge sending module can send ordinary challenge frames and honeypot messages by mixing path_ref and frame_mix_ref; the response sampling module can generate summaries based on hardware timestamps, controller return status, error frame statistics, and local cache records. The rule management module can maintain different timing_profile_ref and honey_policy_ref according to vehicle type, bus type, path location, terminal hardware level, and risk control level. Detailed Implementation

[0026] Implementation Method 1: Bus Challenge Object Issuance like Figure 2 As shown, the server sends a bus challenge object to the vehicle terminal. The bus challenge object can include at least one or more of the following: challenge_seq_ref, timing_profile_ref, honey_frame_ref, policy_ver, epoch_nonce, path_ref, retry_policy_ref, load_bucket_ref, honey_policy_ref, and timing_guard_ref. challenge_seq_ref indicates the challenge frame sequence, timing_profile_ref indicates the transmission time template, and honey_frame_ref indicates the honeypot message template.

[0027] The server can select different challenge targets based on vehicle platform, current risk level, historical path stability, and business time period. For low-risk targets, a shorter `challenge_seq_ref` can be used; for targets suspected of hardware insertion, the `honey_frame_ref` ratio can be increased, the `timing_profile_ref` complexity can be increased, or the `path_ref` can be switched. If the terminal finds that the current operating conditions do not allow the execution of the challenge locally, such as bus overload, critical control phase, or violation of `timing_guard_ref`, it can postpone execution and return `defer_reason_ref`.

[0028] Implementation Method 2: Challenge Frame Transmission and Response Sampling The vehicle-mounted terminal sends challenge frames or honeypot messages on a preset bus path based on the bus challenge object, and can simultaneously generate passive noise observation objects. The passive noise observation object can include at least one or more of the following: electromagnetic noise sampling summary, noise energy distribution summary, noise burst distribution summary, or noise-load state coupling summary. The vehicle-mounted terminal further collects one or more of the following: response delay summary, delay jitter summary, inter-frame interval summary, missing response summary, abnormal rearrangement summary, error frame summary, and local congestion summary, which, together with the passive noise observation object, form a bus challenge response object. The sampling object does not require uploading the complete original bus stream, but rather uploads a verifiable summary result.

[0029] The response delay summary can include at least one or more of challenge_tx_ts_ref, first_resp_delay_bucket, tail_delay_bucket, and jitter_bucket_ref. The inter-frame interval summary describes the time difference distribution between adjacent responses; the message period coupling summary describes the period offset results before and after the challenge, the period recovery speed results, or the period anomaly consistency results; and the anomaly reordering summary describes anomalies in the response order under the order set by challenge_seq_ref. If some paths do not return standard responses, missing summaries, error status summaries, or controller-level local feedback can also be collected.

[0030] Implementation Method 3: Local Timing Correction and Load Normalization The vehicle-mounted terminal performs local corrections on the sampling reference, clock error, and bus load using a local timing correction module. Load normalization is particularly important because the bus itself may exhibit different delay distributions under high and low loads. The terminal can correct or annotate the latency, message periodicity coupling results, and electromagnetic noise coupling results in the bus challenge response object based on load_bucket_ref, controller busy / idle status, error frame density, and normal service traffic within the sampling window.

[0031] This design allows the server to distinguish between "natural jitter caused by real bus congestion" and "structured forwarding delay introduced by relay hardware" when identifying anomalies. Without load normalization, many normal scenarios might be misjudged as plug-in relays; completely ignoring load differences would weaken the system's ability to identify conditional forwarding hardware.

[0032] Implementation Method 4: Honeypot Message Design and Processing Result Analysis like Figure 3As shown, the honeypot message corresponding to honey_frame_ref is designed to be objects that should not be actively processed by normal service links, and are only used to detect abnormal forwarding logic or are easily triggered by error handling in specific relay hardware. The honeypot message can be a harmless test frame in the normal identifier space, or a special sequence frame that is constrained by rules and will not affect the real control logic.

[0033] Figure 3 The invention does not express a single conclusion about whether or not a honeypot message is responded to. Instead, it simultaneously generates a response delay summary, a honeypot response anomaly summary, and a noise coupling summary for the same challenge session, and binds these three summaries as relay detection objects used for subsequent joint determination. Through this object-oriented expression, examiners can directly understand that the invention does not rely on the hit or miss of a single honeypot message, but rather on multiple types of timing and coupling features to jointly support anti-hardware relay determination.

[0034] The server adjusts its hardware relay risk score based on one or more of the following: honeypot packet handling results, missing response results, abnormal rearrangement results, latency coupling results, and electromagnetic noise coupling results. For example, if a normal path should ignore honey_frame_ref, but a certain path consistently shows stable responses, latency compensation, abnormal filtering, or abnormal noise synchronization changes, it indicates that there may be relay hardware in the path that parses and processes honeypot packets.

[0035] Implementation Method 5: Joint Coupling Analysis of Latency, Jitter, Missing Information, and Out-of-Order Consequences The server does not use a single average latency as a criterion, but rather makes a joint judgment based on the following results: 1. Is the distribution difference between minimum delay and tail delay abnormally widening? 2. Does jitter bucketing undergo structural changes after honeypot packet injection? 3. Are missing responses concentrated in a specific subset of challenge_seq_ref? 4. Is the response order abnormally rearranged under certain timing_profile_refs? 5. Do error frames or controller feedback occur synchronously with latency anomalies?

[0036] Coupling analysis can more effectively distinguish between natural bus fluctuations and patterned anomalies caused by plug-in relays. This is because many hardware relays do not exhibit anomalies across all metrics, but rather reveal structural deviations under specific challenge combinations, honeypot ratios, or bus loads.

[0037] Implementation Method Six: Historical Path Baseline and Path Bucketing `path_ref` can be used to indicate OBD paths, CAN paths, LIN paths, local subbus paths, or combinations thereof. Different `path_ref`s can maintain different historical path baselines. The server can further construct more granular path bucket baselines based on vehicle model, installation location, terminal version, and `load_bucket_ref`.

[0038] When the current bus challenge response deviates significantly from the corresponding path baseline, the server does not immediately reject it. Instead, it comprehensively considers whether honeypot anomalies, out-of-order anomalies, missing anomalies, and whether it is consistently incompatible with the historical path baseline. For paths that are stable in the long term but have slight deviations, the observation results can be output and the complexity of subsequent challenge_seq_ref can be increased; for paths that clearly hit honeypot message anomalies and structured latency anomalies, the risk level can be directly increased.

[0039] Implementation Method Seven: Risk Stratification and Supplementary Evidence Path like Figure 4 As shown, the server generates hardware relay risk results based on one or more of the following: latency offset results, jitter coupling results, honeypot packet handling results, historical path baseline deviation results, device continuity summary, near-field interaction summary, anomaly template results, and anomaly replay results. The device continuity summary may include at least one or more of the following: session continuity, recent disconnection results, abnormal restart results, or challenge window coverage results. The anomaly template results may include at least one or more of the following: known relay latency template, known out-of-order template, known honeypot mishandling template, or known noise coupling template. If the risk score is low, a pass result is output; if there is a minor anomaly, an observation result or a supplementary verification result is output; if honeypot packets are abnormally forwarded, the latency pattern is significantly abnormal, the out-of-order pattern is significantly abnormal, or the path baseline is severely deviated, a rejection result or a high-risk anomaly result is output.

[0040] Supplementary verification paths can include re-issuing different timing_profile_refs, reducing or increasing the honey_frame_ref ratio, switching path_refs, switching read-only loopback observation templates, or extending the observation window. Through these supplementary verification paths, the system can avoid strong conclusions directly resulting from a single anomaly, while also enabling more targeted secondary verification of suspected objects.

[0041] When a high-risk anomaly is detected, in addition to outputting a relay suspicion result, the server may further output one or more of the following: a freeze result, a request for supplementary evidence, or a dispute review result. A freeze result can be used to temporarily block a high-risk path from being considered a trusted source until supplementary evidence or manual review is completed.

[0042] Implementation Method 8: Abnormal Replay and Cache Forwarding Identification Some relay hardware may cache the response pattern from the previous round of `challenge_seq_ref` and perform approximate replay in subsequent windows. Servers can identify this behavior by considering `epoch_nonce`, `challenge_seq_ref`, and local anomaly sequence signatures. Anomaly replay scores can be improved if an object exhibits unreasonably similar response latency summaries and honeypot processing patterns across different `epoch_nonce`s.

[0043] The buffer forwarding hardware may also leave special traces in the latency tail, out-of-order boundaries, or honeypot packet processing. Servers can use these asymmetric characteristics to distinguish between "real bus congestion" and "relay buffer replay".

[0044] Implementation Method Nine: Idempotency and Deduplication Expansion The server can construct evidence identifiers based on one or more of challenge_seq_ref, path_ref, policy_ver, epoch_nonce, and response_sig_ref to perform idempotent deduplication on repeatedly reported bus challenge response objects. Receipts may include at least one or more of OK, OK_DUP, REVIEW, RETRY, and REJECT, and may include a reference to the next round of supplementary evidence policy.

[0045] Implementation Method 10: Dispute Review and Controlled Disclosure like Figure 5 As shown, in a disputed scenario, the server can issue an audit request. The audit request may include at least one or more of the following: auth_token, field_mask, epoch_nonce, proof_scope_ref, dispute_id, and reveal_policy_ref. The vehicle terminal returns a set of controlled disclosure fields based on the field mask, and the server uses this to verify the consistency between the bus challenge response object and the risk result.

[0046] The `field_mask` option only allows the disclosure of the minimum necessary summary fields, such as the disposal results of certain `delay_bucket`, `jitter_bucket`, specific `honey_frame_ref` fields, and some out-of-order statistics, without disclosing the complete challenge sequence or the complete bus sampling stream. This controlled disclosure reduces the risk of attackers reverse-engineering system rules from the disputed interface while ensuring auditability.

[0047] Implementation Method Eleven: Deployment of Bus Anti-Relay and Wireless Ranging Offloading The server can explicitly limit the result of this invention to the determination of whether a plug-in hardware relay or conditional filtering module exists in the bus physical path, rather than describing it as a spatial distance measurement result between a mobile phone, key, or terminal. If a near-field interaction summary exists, it is only used as auxiliary input or supplementary material, not as the primary criterion of this invention. This boundary avoids the invention falling back into the technical jargon of wireless RTT, UWB, or fine ranging.

[0048] Implementation Method Twelve: Failure Protection and Deployment of Safe Execution Boundaries The terminal must ensure that the transmission of `honey_frame_ref` and `challenge_seq_ref` does not affect critical control messages or violate the bus protocol security boundaries. If the current `path_ref` is in a critical control phase, the bus error state is too high, or `timing_guard_ref` is not met, the terminal may refuse to execute the challenge and return `defer_reason_ref`. This protection boundary enables the invention to be implemented under production-ready conditions without relying on dangerous, highly intrusive testing.

[0049] Implementation Method Thirteen: Examples of Typical Scenarios For example, in a vehicle's OBD path, an attacker inserts a transparent forwarding box. This forwarding box normally forwards regular service frames quickly, but buffers and conditionally discards certain unidentified frames. The server sends a challenge_seq_ref containing honey_frame_ref to the terminal. After the terminal executes the request, local sampling reveals only a slight increase in latency for regular challenge frames, but honeypot packets exhibit abnormal responses and reordering under a specific timing_profile_ref, and this phenomenon repeats across different epoch_nonces. The server, combining historical path baselines, determines that this object poses a high hardware relay risk. This example demonstrates that the present invention can identify inserted forwarding hardware that is not fully exposed to ordinary passive eavesdropping.

[0050] Implementation Method Fourteen: Honeypot Message Classification and Management Honeypots can be categorized into several types, including silent, induced response, sequence perturbation, conditional filtering / inducing, and read-only loopback observation. Silent honeypot messages should be ignored in real-world scenarios. Inducing response honeypot messages are used to detect whether relay hardware will generate incorrect responses. Sequence perturbation honeypot messages are used to observe whether relay links cause out-of-order delivery after buffering. Conditional filtering / inducing honeypot messages are used to observe whether specific identifiers, specific location combinations, or specific time and location trigger abnormal forwarding logic. Read-only loopback observation honeypot messages are used to observe the forwarding and return characteristics of read-only test objects without triggering service actions. Servers can select different types of honeypots based on risk levels to improve detection coverage.

[0051] Passive noise observation objects can be generated in parallel with challenge frame objects, or they can be collected before and after challenge_seq_ref to form a before-and-after comparison. The server incorporates noise energy distribution summaries, noise burst distribution summaries, and noise-to-message period correlation summaries into the electromagnetic noise coupling results to identify additional noise patterns introduced by relay hardware during forwarding, buffering, or filtering.

[0052] Implementation Method Fifteen: Multi-round Challenges and Cross-validation The server can issue multiple rounds of `challenge_seq_ref` in adjacent windows, and alternately adjust `timing_profile_ref`, `frame_mix_ref`, and `load_bucket_ref`. If an object is anomalous only under a certain type of honeypot message, but completely normal under other templates, the system can continue to supplement the verification; if multiple templates point to the same structured anomaly, the relay risk score can be significantly improved. The value of multi-round challenges lies in reducing misjudgments caused by sporadic congestion or controller scheduling fluctuations.

[0053] Implementation Method Sixteen: Adapting Installation Position Differences to Harness Length Different terminal installation locations, wire harness lengths, and interface conversion methods will naturally introduce certain latency differences. The server can further subdivide `path_ref` into `install_bucket_ref`, `wire_length_bucket_ref`, and `adapter_profile_ref`. This avoids misinterpreting actual installation differences as hardware repeaters, while still retaining the ability to identify abnormal additional latency and abnormal out-of-order patterns.

[0054] Implementation Method Seventeen: Deploying the Upper Safety Boundary in Mass Production Operation The design of `challenge_seq_ref` and `honey_frame_ref` should meet production safety boundaries, such as not affecting critical control frames, not conflicting with regulatory requirements, and not being triggered under safety-critical operating conditions. The terminal-locally maintainable `challenge_enable_flag` executes challenges only during parking, low-risk operating segments, or non-critical time slots permitted by rules. Through this safety upper bound, this invention can operate long-term on real vehicles, rather than being limited to laboratory benches.

[0055] Implementation Method 18: Troubleshooting and Manual Review Guidelines When an object remains in a REVIEW or OBSERVE state for an extended period, the server can output troubleshooting suggestions without internal template details, such as checking OBD physical connectors, checking for additional adapter modules, or checking for any abnormally installed devices. The manual review system, under high privileges, can further read the handling result summary and path baseline deviation summary for a specified honey_frame_ref to assist in on-site troubleshooting. This hierarchical design allows mass production operations personnel and high-privilege auditors to see information appropriate to their respective responsibilities.

[0056] Implementation Method Nineteen: Controller Type Differences and Path Profiling The bus controller type, transceiver model, and interface electrical characteristics may differ significantly across vehicle platforms. The server can build path profiles around `controller_profile_ref`, `transceiver_profile_ref`, and `path_profile_ref`. This allows the system to reference the profile matching the specific platform when interpreting latency and jitter results under `challenge_seq_ref`, rather than directly applying a unified cross-platform threshold.

[0057] The path profiling not only describes the average latency level, but also the typical jitter band, common error frame density, acceptable periodic coupling range, and normal response pattern of silent honey_frame_ref. Through this layer of modeling, this invention can avoid misjudging platform differences as relay hardware anomalies and makes anti-relay strategies more portable for mass production.

[0058] Implementation Method 20: Challenge Scheduling Slots and Safety Windows The terminal can select the challenge execution slot based on `ignition_state_ref`, `vehicle_mode_ref`, `bus_utilization_ref`, and `safety_slot_ref`. Some `challenge_seq_ref`s are only allowed to execute during parking, low-speed, or non-critical control phases; some read-only observational `honey_frame_ref`s can execute within a more lenient window. If the terminal finds that the current `safety_slot_ref` is invalid, it can postpone the challenge instead of forcing its execution.

[0059] By objectifying challenge scheduling and safety windows, this invention explicitly discloses "how to perform anti-relay detection without interfering with normal control." This is crucial for examiners to assess feasibility, as one of the core challenges in the field of vehicle bus systems is ensuring that detection actions do not disrupt the original control path.

[0060] Implementation Method 21: Deploying Honeypot Message Categories and Risk Gradients The server can further classify honey_frame_ref into multiple levels from risk_grade_1 to risk_grade_n. Lower-level honeypot messages are more inclined towards silent observation, used only to detect the presence of abnormal responses; higher-level honeypot messages emphasize features such as out-of-order delivery, conditional filtering, and cached replay, but still need to meet the security constraint of not triggering real control actions. The server can gradually increase or decrease the level of the honey_frame_ref used based on historical risk results.

[0061] The advantage of this risk gradient is that the system does not have to apply the most complex checks to all objects at once. Low-risk objects can use less invasive honeypots and latency templates, while high-risk objects are gradually subjected to more stringent cross-validation. This helps control power consumption and bus disturbances, and also provides a tiered operational strategy space for mass production deployment.

[0062] Implementation Method 22: Local Clock Calibration and Timing Reliability Deployment Before the challenge begins, the terminal can generate `timing_quality_ref`, `clock_drift_ref`, and `sync_source_ref` to indicate whether its local timing capabilities are sufficient to support the current judgment. If the timing capabilities are insufficient, even if a response delay summary is collected, the result can be downgraded to supplementary material rather than used as a direct rejection criterion. This avoids misjudging local clock inaccuracies as relay insertion delays.

[0063] The terminal can also perform duplication checks on the measurement paths of challenge_tx_ts_ref and first_resp_delay_bucket, such as comparing the compatibility of the controller timestamp with the high-precision timer, or comparing the jitter range of adjacent idle windows. Through timing reliability governance, this invention includes the reliability of the measured delay itself within the scope of disclosure, thereby further enhancing the implementation details.

[0064] Implementation Method 23: Separation of Natural Congestion and Abnormal Forwarding The server can model congestion_signature_ref and relay_signature_ref separately. Natural congestion typically manifests as an overall increase in latency and jitter spread, but with weak regularity, as bus_utilization_ref increases. Abnormal forwarding, on the other hand, is more likely to exhibit repetitive structured offsets under specific challenge_seq_ref, honey_frame_ref, or timing_profile_ref. The server can use this to distinguish between "reasonable high load" and "abnormally regular latency under low load".

[0065] If the current window's `bus_utilization_ref` is extremely high, the system can output the observation and request a supplementary window for verification, instead of directly issuing a strong rejection. This design reduces false positives while retaining sensitivity to genuine structured relay behavior. For examiners, this demonstrates that the invention does not equate all latency anomalies with attacks, but rather discloses implementable traffic splitting rules.

[0066] Implementation Method 24: Deployment of Advanced Relay Behavioral Patterns Some advanced hardware relays may possess capabilities such as caching, conditional filtering, delay shaping, and even identifier-based differentiated forwarding. Servers can identify such patterns around `reorder_cluster_ref`, `delay_shape_ref`, `selective_drop_ref`, and `honey_parse_flag`. For example, if the same object only produces fixed delay shaping for a certain combination of identifiers, while remaining approximately transparent to ordinary service frames, it may be suspected of having rule-driven filtering capabilities.

[0067] The system does not require a one-time identification of the entire internal implementation of the relay hardware. Instead, it gradually collects its external behavioral characteristics under different templates through multiple rounds of challenge_seq_ref. As long as these external characteristics remain stable and reproducible across multiple windows, it is sufficient to support the server in raising its risk level. This description further enhances the invention's full disclosure of complex attack surfaces.

[0068] Implementation Method 25: Multi-path Cross-validation Deployment Terminals can perform challenges or observations around multiple path_refs, such as OBD paths, local subbus paths, and read-only loopback paths. If an object exhibits a structured anomaly only on one path while remaining normal on other paths, the server can infer that the anomaly is more likely located near a specific transition segment or insertion module; if similar anomalies occur simultaneously on multiple paths, the global relay risk score can be improved.

[0069] The advantage of multi-path cross-validation lies in its ability to narrow down the scope of problem localization. For mass production deployment and after-sales troubleshooting, this means that the system can not only determine "whether there is a suspected relay," but also provide more specific path-level guidance for subsequent troubleshooting, thereby enhancing the value of project implementation.

[0070] Implementation Method 26: Evidence Sealing and Replay of Evidence The server can encapsulate the bus challenge response object, rule version reference, honey_frame_ref disposal result summary, and path baseline deviation summary into a sealed_evidence_ref. The sealed_evidence_ref can be stored in read-only mode and recalculated around the same rule version reference and path_profile_ref during disputes or compliance checks. If the recalculation results are consistent, the stability of the original disposal can be proven; if inconsistent, it can be determined whether the issue stems from a rule upgrade or data anomalies.

[0071] The terminal can also temporarily retain references to protected partial replay materials, such as partial delay buckets and noise digest references within a specified window, but these are not accessible to business systems by default. Through evidence sealing and playback paths, this invention further discloses traceability capabilities during dispute auditing.

[0072] Implementation Method 27: Deployment of Fleet Group Baselines and Rule Governance The server can create `fleet_path_baseline_ref` for objects of the same vehicle model, installation method, and interface adapter. If a batch of vehicles generally experiences a slight increase in latency under the same rule version reference, but the number of honeypot message anomalies does not increase, it may indicate a platform-level change or controller batch difference, rather than a large-scale relay attack. The server can then optimize the boundaries of `path_profile_ref` or `install_bucket_ref` accordingly.

[0073] By using fleet-wide baseline management, this invention can reduce false alarms caused by batch variations while maintaining the ability to identify individual abnormal paths. This section helps examiners understand the governance approach of this invention in large-scale production fleets, rather than just in single-vehicle experimental scenarios.

[0074] Implementation Method 28: Diversion of After-sales Transfer Parts and Legal Modifications After-sales service may legally add diagnostic adapters, data acquisition modules, or authorized maintenance equipment to vehicles. These devices may introduce measurable additional latency, but their behavior is not entirely the same as malicious relaying. Terminal or backend systems can log adapter_profile_ref, service_tool_ref, and maintenance_window_ref to explain the legitimate context of a path change.

[0075] If the adapter_profile_ref is largely consistent with the observed latency change direction, and there is no honeypot mishandling, abnormal out-of-order delivery, or selective discarding, the system can maintain the observation results instead of directly rejecting the request. If a legitimate modification declaration exists but the behavior pattern still clearly matches relay_signature_ref, the system can still maintain the high-risk assessment. This allows for the differentiation between legitimate operational changes and malicious relaying.

[0076] Implementation Method 29: Rule Rollback and Remote Upgrade Rule version references, honey_policy_ref, and timing_profile_ref can all be adjusted via remote upgrades. To prevent false alarms introduced by the upgrade strategy itself, the server can create rollback_rule_ref and rollback_trigger_ref for each upgrade. If the observe_rate or review_rate of a certain path profile increases abnormally after the upgrade, it can automatically revert to the old rule while retaining the grayscale analysis records.

[0077] This invention discloses a secure iterative detection strategy for long-term operation and maintenance through remote upgrades and rule rollback mechanisms. This not only meets the practical deployment requirements of in-vehicle systems but also enhances the sufficiency of the engineering governance layer disclosed in the specification.

[0078] Implementation Method Thirty: Evaluation of Operational Indicators and Deployment Effectiveness The server can continuously collect statistics on metrics such as pass_rate_ref, observe_rate_ref, review_rate_ref, sealed_evidence_usage_ref, and false_alarm_reopen_rate_ref, and analyze them separately by vehicle type, path_profile_ref, and honey_frame_ref category. If a silent honeypot message fails to provide effective differentiation across multiple platforms for an extended period, its usage frequency can be reduced; conversely, if a sequence-perturbation template exhibits a significantly high recognition rate under a specific relay mode, its usage weight on high-risk targets can be increased.

[0079] By incorporating deployment effectiveness evaluation into a continuous governance loop, this invention not only provides the detection logic but also outlines the path for measuring its effectiveness, identifying problems, and optimizing strategies in real-world operations. This brings the specification closer to a mass-producible technical solution, rather than remaining at the conceptual level.

[0080] Implementation Method Thirty-One: Field Encoding and Controller-Independent Expression Expansion The `delay_bucket`, `jitter_bucket`, `error_frame_bucket`, and `reorder_stat_ref` in the bus challenge response object can be uniformly mapped to a controller-independent digest encoding, without directly relying on a particular controller vendor's proprietary register format. The terminal only needs to convert its local controller output to the common encoding and then report it along with `controller_profile_ref`. The server performs cross-platform comparisons based on the common encoding, and only references `controller_profile_ref` for interpretation when deeper troubleshooting is required.

[0081] This irrelevant expression helps the invention reuse across different bus controllers and diagnostic interface implementations, while avoiding excessive binding of the specification to a single hardware platform. For the examiner, this demonstrates that the invention possesses a clear data abstraction layer.

[0082] Implementation Method 32: Template Selection for Supplementary Evidence Link When the server detects that an object exhibits only mild anomalies within a specific `honey_frame_ref` category, it can generate a `supplement_chain_ref`. This chain doesn't necessarily replicate the original challenge; instead, it can select a template more suitable for the current anomaly type. For example, it can change a silent honeypot to a sequential perturbation type, a short sequence to a long sequence, or a single-path observation to multi-path cross-validation. Through `supplement_chain_ref`, secondary validation can more effectively distinguish between sporadic noise and structured relays.

[0083] The server can also attach expected improvement goals to `supplement_chain_ref`, such as confirming whether conditional filtering exists, confirming whether cache re-placing occurs, and confirming whether anomalies only occur in specific installation locations. In this way, the supplementary certification is upgraded from "duplicate detection" to "targeted verification," and the technical disclosure is more complete.

[0084] Implementation Method 33: Multi-session Association and Abnormal Persistence Deployment The server can track the persistence of anomalies on the same path across multiple epochs using the session_cluster_ref. If an anomaly occurs only briefly within a single session, the system can maintain observation; however, if the same relay_signature_ref is reproduced across multiple sessions under different loads and different timing_profile_refs, the risk level can be significantly increased. This multi-session correlation mechanism can suppress false alarms caused by occasional jitter.

[0085] `session_cluster_ref` can also be used to identify the "intermittent operating mode" of relay devices. Some adversaries only enable the forwarding module during specific periods or under specific triggering conditions. Multi-session clustering can reassemble these scattered anomalies into stable patterns, thereby improving identification capabilities.

[0086] Implementation Method Thirty-Four: Deployment of Regulatory Evidence Collection and Third-Party Re-verification Interfaces High-privilege monitoring systems or entrusted third-party laboratories can obtain a limited re-verification interface based on `sealed_evidence_ref` and `replay_scope_ref` under legal conditions. This interface only outputs the minimum summary and rule version references required for replay, and does not directly expose all honeypot template plaintext. The third-party re-verification system can recalculate the risk results in an isolated environment based on the same rule version references and compare whether the original conclusions are consistent.

[0087] Through a third-party verification interface, this invention further demonstrates that its results can not only be interpreted by the internal system but also verified by a high-authority external entity under controlled conditions. This directly assists examiners in determining whether the technical solution is sufficiently disclosed and whether it possesses verifiability.

[0088] Implementation Method Thirty-Five: Long-Term Fleet Management and Retirement Transfer Part Identification During long-term fleet operation, there may be instances where certain types of retired adapters are repeatedly transferred and installed between different vehicles. The server can identify whether multiple vehicles share similar abnormal path characteristics by using a combination of adapter_profile_ref, relay_signature_ref, and fleet_path_baseline_ref. If multiple vehicles exhibit highly similar abnormal templates at different times, the platform may suspect that the same type of adapter is being repeatedly used and will raise the alert level for the entire fleet.

[0089] This fleet-level governance logic extends the invention from single-vehicle detection to group risk assessment, while still maintaining path_ref, honey_frame_ref, and challenge response summaries as the core technologies. This enhances its engineering application value without deviating from the invention's core principle of anti-hardware relay.

[0090] Implementation Method Thirty-Six: Relay Detection Freeze and Recovery Deployment If an object has repeatedly triggered high-level `relay_signature_ref` and `sealed_evidence_ref` signals and is already locked by regulators or its manual review is not yet complete, the server can set `relay_freeze_ref` on it. While in a frozen state, the system can halt normal business trust enhancement, allowing only read-only certificate supplementation or manually guided challenges. If subsequent manual review confirms no malicious relaying, the server can restore normal path governance via `freeze_release_ref`.

[0091] By employing a freeze and restore mechanism, this invention discloses a complete governance process from "discovering a highly suspicious anomaly" to "restoring the system to normal status," thus preventing the system from continuing to make unnecessary normal trust judgments under high-risk conditions.

[0092] Implementation Method 37: Cross-Interface Bridging Identification Deployment Some faulty devices may bridge different physical interfaces, such as inserting switching logic between OBD and local subbus. The system can compare the differences in latency, out-of-order delivery, and honeypot mishandling under different path_refs around bridge_pattern_ref. If an object only exhibits structured anomalies in cross-interface paths, but is relatively normal within a single path, it can be inferred that it is more likely to belong to a bridged forwarding module.

[0093] Bridging identification is of great value for after-sales troubleshooting and anomaly localization, and it further illustrates that the present invention does not only make coarse-grained judgments on a single path, but can provide more detailed technical processing for complex physical connection forms.

[0094] Implementation Method Thirty-Eight: Challenging Sequence Randomization and Anti-Prediction Deployment `challenge_seq_ref` introduces controlled randomization, including frame order fine-tuning, interval jitter template switching, and honeypot ratio variations, provided that `timing_guard_ref` and security upper bounds are met. The randomization strategy is managed by `anti_prediction_ref`, and server and terminal interpretation is ensured through rule version references. Its purpose is to reduce attackers' ability to predict fixed challenge patterns.

[0095] Randomization is not entirely random, but rather confined to a set of verified and secure templates. This ensures detection coverage without subjecting normal paths to unnecessary risks due to excessive randomness. Through this design, the invention's ability to counter advanced learnable relays is further disclosed.

[0096] Implementation Method Thirty-Nine: Anomaly Review and Template Repair Manually confirmed anomalies can be converted into replay_case_refs for subsequent template patching. The platform can analyze whether the case is most likely to be exposed under silent honeypots, sequential perturbation templates, or read-only loopback templates, and revise honey_policy_ref or timing_profile_ref accordingly. The revised policy is first verified in a gray-scale fleet before being expanded to a wider scope.

[0097] By creating a closed loop of anomaly review and template repair, this invention expands from "detecting an anomaly once" to "how to use anomalies to continuously improve the detection system", making the instruction manual closer to the real requirements of long-term mass production operation and maintenance.

[0098] Implementation Method Forty: Equipment Decommissioning, Dismantling, and Evidence Sealing Completed When a terminal, interface adapter, or suspected transition device is formally removed, decommissioned, or sent for inspection, the system can generate `deinstall_ref` and `final_seal_ref`. `deinstall_ref` is used to mark that subsequent collection of routine challenge results for the same path will no longer be possible; `final_seal_ref` is used to encapsulate previously accumulated `sealed_evidence_ref`, manual review results, and maintenance results into a read-only archive. This prevents decommissioned equipment from continuing to participate in normal judgment and facilitates subsequent accountability.

[0099] By providing a clear explanation of the post-processing management of abnormal equipment through the decommissioning and storage completion path, this invention avoids the technical chain from only covering "discovering the problem" without covering "how to archive after the problem is resolved".

[0100] Implementation Method 41: Collaborative Auditing Across Organizations Fleet operators, equipment suppliers, after-sales service providers, and regulators may each have access to information at different levels. The system can control the range of fields visible to each party through `audit_scope_ref` and `organization_role_ref`. Operators only see status codes and troubleshooting suggestions; suppliers can see controller profiles and template categories with authorization; and regulators can read a more complete `sealed_evidence_ref` structure but still do not directly obtain all honeypot plaintext.

[0101] Through cross-organizational collaboration mechanisms, this invention further discloses how to maintain the integrity of the chain of evidence while controlling the leakage of rule details in complex collaborative scenarios. This directly aids in implementability and review comprehension.

[0102] Implementation Method 42: Long-Term Path Drift and Chronic Anomaly Unfolding Some path anomalies are not one-off, inserted relays, but rather chronic anomalies caused by connector aging, localized shielding degradation, or unstable adapter contact. Servers can track these long-term, slow changes around `path_drift_ref` and `longtail_noise_ref`. If an object does not hit the typical `relay_signature_ref`, but exhibits progressively worsening jitter tails and noise coupling expansion over a long period, the system can proceed to `maintenance_suspect_ref` instead of directly concluding it's a malicious relay.

[0103] By managing chronic abnormal paths, this invention clearly separates "malicious relays" from "degraded paths requiring maintenance." This reduces false alarms and provides more practical troubleshooting value for mass production operations and maintenance.

[0104] Implementation Method 43: Template Deactivation, Replacement, and Historical Compatibility Some honey_frame_refs or timing_profile_refs may prove insufficiently discriminative, have a high false positive rate, or be incompatible with new platforms after long-term use. The platform can generate a template_retire_ref for these templates and specify a replacement_template_ref. The old template will no longer be used in new sessions after retirement, but historical sealed_evidence_refs can still be referenced during audit replays to maintain the verifiability of historical conclusions.

[0105] This historical compatibility path is crucial because it demonstrates that the invention will not invalidate existing evidence as the strategy evolves. The auditing system can still replay historical decisions based on old templates and rule versions, while the operating system continues detection using the updated template, thus balancing continuous optimization with historical consistency.

[0106] Implementation Method 44: Deployment of Post-hoc Triage for Fault Repair and Malicious Relay If a path was previously flagged as a high-risk relay suspect, and subsequently repaired, disassembled, or had its adapter removed, the platform can re-examine its `delay_shape_ref`, `honey_parse_flag`, and `congestion_signature_ref` values ​​based on `remediation_review_ref` to see if they have returned to normal. If multiple windows return to the healthy range after repair, it indicates that the previous anomaly was more likely related to a faulty adapter or abnormal modification; if the repair statement exists but the path characteristics remain almost unchanged, the platform can maintain the high-risk conclusion. This allows for retrospective traffic separation between scenarios where "the fault has been repaired" and "the malicious relay still exists."

[0107] This design demonstrates that the present invention does not only provide a one-time judgment, but can re-verify the health status of the path after subsequent maintenance actions, forming a complete operation and maintenance closed loop.

[0108] Implementation Method 45: Deployment of Conservative Handling Protocols for High-Sensitivity Paths For security-sensitive paths, critical buses, or high-value service trigger periods, the server can enable `conservative_relay_policy_ref`. This policy requires a lower tolerance threshold, a longer review window, and stricter multi-path consistency support. Even if the current anomaly is insufficient to trigger a freeze on a normal path, a `REVIEW_HOLD` or temporary freeze result can be output on a high-sensitivity path, and the path can be restored after manual intervention or supplementary verification.

[0109] Through conservative handling protocols, this invention can adapt to vehicles and routes with different risk levels, indicating that it is not a single fixed threshold system, but can implement hierarchical anti-relay governance according to business security levels.

[0110] Implementation Method 46: Sharing Rule Knowledge Base and Supply Chain The platform can store verified relay_signature_ref, bridge_pattern_ref, adapter_profile_ref, and corresponding handling results as relay_casebook_ref. Equipment suppliers, after-sales service providers, or monitoring systems within the supply chain can share the pattern summary within this repository, with authorization, instead of sharing the complete honeypot plaintext. This allows for faster identification of the type of adapter, bridging module, or erroneous installation when a new vehicle exhibits similar anomalies.

[0111] By leveraging a rules-based knowledge base and a controlled sharing mechanism, this invention further discloses its implementation in long-term governance across organizations and enhances its persuasiveness to reviewers: the solution is not only detectable but also supports subsequent supply chain-level collaborative handling.

[0112] in conclusion This invention establishes an anti-hardware relay detection technology chain for vehicle physical bus links through bus challenge objects, bus challenge response objects, honeypot messages, latency and jitter coupling analysis, path baseline comparison, hierarchical processing, and controlled dispute review interfaces. This technology chain can improve the identification capability of transparent repeater boxes, conditional filter boards, and delay insertion modules under real-world mass production deployment conditions, while maintaining a clear boundary with wireless short-range ranging-based anti-relay technologies.

Claims

1. A vehicle-mounted anti-hardware relay method based on bus latency challenge and honeypot detection, characterized in that, The method, executed collaboratively by the vehicle-mounted terminal and the server, includes: the vehicle-mounted terminal generating one or more of the following within a controlled session: a challenge frame object, a honeypot message object, and a passive noise observation object. The challenge frame object includes at least one or more of the following: a challenge timing reference, a message template reference, a sampling window reference, and a rule version reference. The vehicle-mounted terminal injects a controlled challenge into the vehicle bus, the bus controller register layer scheduling path, or the bus observation path based on the challenge frame object, and collects one or more of the following: a response delay summary, a forwarding jitter summary, a message period coupling summary, and an electromagnetic noise coupling summary, forming a relay detection object. The server generates one or more of the following: a relay suspicion result, an observation result, or a rejection result based on one or more of the following: a device continuity summary, a proximity interaction summary, a historical delay baseline, and an anomaly template result. The relay detection object is at least used to characterize hardware forwarding or insertion suspicion on the physical bus link between the OBD interface and the vehicle-mounted terminal, while the proximity interaction summary serves only as an auxiliary consistency input, not the primary criterion. When a high-risk anomaly is detected, the server further outputs one or more of the following: a freeze result, a supplementary verification request, or a dispute review result.

2. A vehicle-mounted anti-hardware relay system based on bus latency challenge and honeypot detection, characterized in that, The system includes an in-vehicle terminal and a server; wherein the in-vehicle terminal includes a bus interface, a delay sampling module, a noise observation module, and a security component, and the server includes an anomaly detection module and a verification module; the system is configured to perform 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 challenge frame object includes at least one or more of the following: a standard frame timing disturbance template, a controlled diagnostic challenge template, a non-service honeypot message template, or a read-only loopback observation template, and is further bound to one or more path references of the following: an OBD path, a CAN path, a LIN path, or a local subbus path.

5. The method according to claim 1, wherein the response delay summary includes at least one or more of the following: single response delay bucket, continuous challenge delay distribution summary, forwarding jitter interval summary, or multi-window stability summary.

6. The method according to claim 1, wherein the message periodic coupling digest includes at least one or more of the following: periodic offset results before and after the challenge, periodic recovery speed results, or periodic anomaly consistency results.

7. The method according to claim 1, wherein the electromagnetic noise coupling summary includes at least one or more of the following: noise energy distribution summary, noise-to-message period correlation summary, noise burst distribution summary, or noise-to-load state coupling result.

8. The method according to claim 1, wherein the server outputs a pass result only when the relay detection object is compatible with the near-field interaction summary, the device continuity summary, the historical latency baseline, and the abnormal template result, and outputs an observation result or a supplementary verification request first when there is a local anomaly.

9. The method according to claim 1, wherein when the relay detection object shows one or more of the following: abnormally high response latency, abnormally consistent forwarding jitter template, honeypot message object showing an unexplained response or noise coupling result that is obviously incompatible with the historical baseline, the server outputs one or more of the following: relay suspicion result, freeze result, or dispute review result, wherein the freeze result is used to suspend the corresponding path as a trusted source before completing the supplementary verification or manual review.

10. The method of claim 1, wherein when a dispute is triggered, the server issues a restricted audit request, the restricted audit request including at least one or more of an authorization token, a field mask, a challenge random number, and an audit scope reference, and the vehicle terminal returns a controlled disclosure field set and a proof bound to the challenge random number based on the restricted audit request to perform a review of the consistency between the relay detection object and the historical latency baseline.

Images