Vehicle-mounted power supply network living body verification method

Abstract

The application discloses a kind of vehicle power supply network living body verification methods.Server issues challenge object, vehicle terminal injects low amplitude challenge incentive to vehicle power supply network and collects response abstract, generates living body fingerprint abstract and living body verification voucher.Server executes verification according to challenge consistency, cross window stability and historical baseline deviation, to distinguish real whole vehicle power supply network, local compensation network and laboratory equivalent simulation network.

Description

Technical Field

[0001] This invention relates to the fields of active excitation, impedance response summary extraction, and physical authenticity verification of vehicle power supply networks, and particularly to a liveness verification method, system, and storage medium for vehicle power supply networks based on active impedance spectrum challenge. Background Technology

[0002] Current vehicle-mounted device authenticity verification solutions typically rely on passively sampling voltage ripple, passively observing bus status, passively recording a continuous heartbeat evidence chain on the device side, or extracting relatively stable environmental fingerprints under fixed operating conditions. While these approaches can provide some reference value in low-attack scenarios, with the emergence of specialized attack tools targeting vehicle-mounted terminals, passive observation alone is no longer sufficient to meet the requirements of high-value risk control, device authenticity verification, and dispute review.

[0003] On the one hand, passive ripple characteristics are easily affected by external power supply stabilizers, ripple compensation circuits, programmable power supplies, and laboratory simulation fixtures. Attackers can add compensation networks to the terminal input side, making the waveform seen by the terminal smoother and closer to historical normal values, thereby weakening the ability of passive sampling to distinguish the real vehicle power supply environment. On the other hand, it is difficult to distinguish between the "real vehicle power supply network," the "fake network after partial compensation," and the "laboratory equivalent simulation network" based solely on natural running textures. Especially in scenarios where attackers can control part of the wiring harness, power supply front-end, or intermediate boards, the passive characteristics read by the terminal do not necessarily represent the complete hardware state of the real vehicle at that moment.

[0004] Furthermore, in scenarios such as high-value risk control, financial leasing, luxury car leasing, and verification of the authenticity of vehicles with high insurance coverage, attackers often do not stop at simply cutting off power or forging identifiers. Instead, they deploy dedicated black boxes to reshape, replay, cache, or conditionally trigger passive features. In this case, even if the server obtains the signed passive digest, it can only confirm that "the terminal did indeed report these fields," but cannot confirm whether "the actual vehicle power supply network actually participated in this verification."

[0005] Furthermore, traditional local device fingerprinting or static power supply fingerprinting often focuses more on the characteristics of single devices, such as the stability characteristics of a certain local branch, a certain fixed load, or a certain fixed frequency point, and it is difficult to incorporate the overall vehicle wiring harness structure, connector status, battery status, local load combinations, aging degree, and overall response relationship under different excitation conditions into the judgment. In other words, existing solutions are more about judging "likeness" than judging "whether it can respond like a real vehicle under current controlled challenges".

[0006] Therefore, it is necessary to propose an active physical authenticity verification scheme. This scheme moves beyond passively observing the power supply network to a collaborative process between the server and the vehicle terminal. Under security gating constraints, low-amplitude, short-duration, and auditable perturbation stimuli are applied to the vehicle's power supply network, and a liveness verification credential is constructed based on the real-time response to these stimuli. In this way, the server can not only determine whether the current response is compatible with historical normal ranges, but also compare cross-session repeatability under the same challenge and structured distinguishability under different challenges. This significantly improves the ability to identify simulators, compensators, locally forged networks, and offline spoofing devices. Summary of the Invention

[0007] Purpose of the invention The purpose of this invention is to provide a liveness verification method, system and storage medium for vehicle power supply networks based on active impedance spectrum challenge, so as to improve the anti-forgery capability, cross-window stability and dispute review capability of vehicle power supply network authenticity verification, and realize a mass-producible, auditable and tiered active liveness verification link without relying on the vehicle manufacturer to open special debugging interfaces.

[0008] Technical solution

[0009] To achieve the above objectives, the present invention adopts the following technical solution: The server issues challenge objects to the vehicle terminal. These challenge objects include at least one or more of the following: excitation sequence reference, frequency band configuration reference, sampling window reference, rule version reference, and session random number reference. Under hardwired gating, the vehicle terminal drives a controlled perturbation unit to inject low-amplitude challenge excitations into the vehicle's power supply network and simultaneously collects one or more of the following: voltage response summary, current response summary, phase offset summary, frequency band energy distribution summary, or impulse response statistical summary, forming an active response object. Based on one or more of the following: vehicle category, temperature binning, voltage reference binning, load state binning, and aging state binning, the vehicle terminal performs compensation and stabilization processing on the active response object, generating one or more of the following: liveness fingerprint summary, response stability result, and challenge consistency result. Subsequently, the security component performs integrity protection on one or more of the following: liveness fingerprint summary, challenge object, window identifier, monotonic counter reference, and compensation version reference, generating a liveness verification credential and sending it to the server. The server performs verification on the liveness verification credentials and outputs one or more verification results, such as pass, observe, supplement verification, or reject, based on one or more of the challenge consistency results, cross-window stability results, historical baseline deviation results, and abnormal replay results. The server further compares the cross-session repeatability results under the same challenge with the distinguishability results under different challenges to distinguish between real vehicle power supply networks, local compensation networks, and laboratory equivalent simulation networks.

[0010] In some embodiments of the present invention, the challenge object may also include one or more of amplitude_bound_ref, duration_bound_ref, retry_policy_ref, sampling_mode_ref, vehicle_profile_ref, install_position_ref, and challenge_batch_ref, to limit the impact of a single challenge stimulus on the normal power supply function of the vehicle and improve the comparability of vehicles of the same model, installation position, and terminal version.

[0011] In some embodiments of this invention, the active response object is not required to upload the complete original waveform, but is composed of one or more of the following: frequency amplitude summary, phase summary, bandwidth energy summary, spectral peak position summary, time-domain attenuation statistical summary, noise bucketing result, load correlation summary, and response quality bitmap. This summary design maintains the server's ability to judge consistency and anomaly levels without exposing high-precision original electrical data, while reducing communication overhead and audit data burden.

[0012] In some embodiments of the present invention, the server maintains a baseline for repetition of the same challenge and a baseline for difference between different challenges around the challenge_id or challenge_batch_ref. The baseline for repetition of the same challenge measures whether the same stimulus condition has stable reproducibility under different sessions and different sampling windows; the baseline for difference between different challenges measures whether the same real vehicle network exhibits the expected structured changes under different stimulus configurations. Locally compensated networks or laboratory equivalent simulation networks can often fit normal responses under individual challenges, but they are difficult to simultaneously satisfy the dual conditions of "stable repetition under the same challenge" and "reasonable changes under different challenges." Therefore, the above-mentioned dual comparison logic can be used to improve the recognition capability.

[0013] In some embodiments of the present invention, the security component allows the output of liveness verification credentials only when the controlled perturbation unit gating is effective, the sampling path is complete, the challenge object binding fields are consistent, the time window is valid, and the local monotonic counter meets the monotonicity requirement. This prevents the business side from bypassing the controlled challenge process and directly forging a passed response result.

[0014] In some embodiments of this invention, the server employs a tiered processing strategy for verification results, rather than a one-size-fits-all approach based on a single threshold. For objects that deviate slightly from the historical baseline but do not reach the level of severe anomaly, observation results or supplementary verification results are output; only when severe incompatibility, repeated playback, timing forgery, or multiple high-risk conditions are encountered are rejection results or high-risk anomaly results output. The server can also construct idempotent key evidence identifiers based on one or more of terminal identifier references, challenge object references, window identifiers, and rule version references, and perform deduplication on duplicate reports, returning receipts such as OK, OK_DUP, REJECT, or RETRY.

[0015] In some embodiments of the present invention, after a dispute is triggered, the server issues a restricted audit request to the vehicle terminal. The audit request may include at least one or more of auth_token, field_mask, challenge_nonce, proof_type, scope_ref, and replay_ref. Based on the audit request, the vehicle terminal returns a controlled set of disclosure fields and a proof bound to challenge_nonce. The server then uses this information to verify the consistency between the liveness fingerprint digest, the active response object, the challenge object, and the compensated version, thereby forming a closed-loop dispute resolution mechanism.

[0016] Beneficial effects

[0017] Compared with the prior art, the present invention has at least the following beneficial effects: 1. By using controlled challenge incentives and proactive response summaries, authenticity verification is elevated from passive observation to challenge-responsive liveness verification, enabling the server to determine not only "whether it resembles a real vehicle power supply network" but also "whether it can respond like a real vehicle power supply network." 2. By incorporating vehicle category, temperature, voltage reference, load, and aging compensation, stability across environments, lifecycles, and installation scenarios is enhanced, reducing the probability of misinterpreting natural variations as attacks. 3. By jointly comparing the repeatability of the same challenge with the distinguishability of different challenges, the ability to differentiate between equivalent simulated networks, locally compensated networks, and black-box replay links is improved. 4. Through security component gating, monotonic counters, and binding field consistency checks, the business side is prevented from bypassing the proactive challenge process and directly forging passing results. 5. By employing idempotent deduplication, layered observation or supplementary verification, restricted audit interfaces, and rule version tracking, the feasibility of the project, subsequent operation and maintenance capabilities, and dispute review capabilities are improved. 6. The main focus of this invention is the liveness verification of the current vehicle power supply network against controlled challenges, rather than focusing on stable key derivation, fingerprint commitment value recovery, or unique binding gating, thus forming a clear boundary with the existing impedance PUF technology that focuses on unique binding. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the overall structure of the active impedance spectroscopy challenge and liveness verification system according to one embodiment of the present invention.

[0020] Figure 2 This is a schematic diagram of the process of issuing challenge objects, collecting active responses, and generating objects in one embodiment of the present invention.

[0021] Figure 3 This is a schematic diagram illustrating the process of comparing repeatability of the same challenge and distinguishability of different challenges in one embodiment of the present invention.

[0022] Figure 4 This is a schematic diagram of the server-side layered verification and idempotent receipt process in one embodiment of the present invention.

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

[0024] Terminology and Object Conventions To facilitate understanding of this invention, some objects and terms are explained uniformly below. The `challenge_id` can represent a single challenge number or a unique index within a batch of challenges. The `excitation_profile_ref` can represent a reference to the excitation waveform category, timing template, frequency set, duty cycle, or a combination thereof. The `band_config_ref` can represent a reference to the band boundary, frequency density, sampling bandwidth, and filter template. The window reference can represent a sampling window or session window identifier. The `comp_ver` can represent a reference to the compensation parameter version. The `repeatability_ref` can represent a reference to repeated sampling results under the same challenge configuration, and the `separability_ref` can represent a reference to differential results under different challenge configurations.

[0025] Without ambiguity, the term "liveness fingerprint digest" in this paper does not imply the generation of a stable key or a uniquely bound identity, but rather represents a summary of the liveness response state of the vehicle's power supply network under the current challenge conditions. The term "active response object" in this paper refers to the set of response results collected and normalized around controlled challenge stimuli; this can be a summarized object rather than complete waveform plaintext. The term "real vehicle power supply network" in this paper refers to the actual network environment under the combined influence of vehicle wiring harnesses, connectors, batteries, local loads, mounting locations, and actual electrical coupling states.

[0026] System Structure like Figure 1 As shown, the system corresponding to this invention includes at least: 1. Controlled perturbation unit for injecting low-amplitude challenge stimuli into the vehicle power supply network; 2. Sampling circuit for acquiring summaries of voltage response, current response, or phase shift; 3. Processor for performing challenge object parsing, active response object construction, compensation, and stabilization processing; 4. Security components for providing gating, integrity protection, counter management, and credential generation; 5. Local parameter management module for managing vehicle model, installation position, compensation version, and policy version; 6. Server-side challenge distribution module, verification module, baseline management module, rule management module, and auditing module.

[0027] The controlled perturbation unit can be one or more of a low-amplitude pulse injection circuit, a frequency sweep excitation circuit, a pseudo-random sequence output circuit, or a multi-frequency composite excitation circuit. The excitation path is bound to the safety component through hard-wired connections or equivalent non-bypassable gating. The sampling circuit includes at least one voltage sampling path and at least one current sampling path. Alternatively, only one of them can be selected according to cost constraints, and combined with the indirect estimation results of phase or time-domain attenuation to form an active response object.

[0028] The server-side baseline management module can maintain different baseline sets according to vehicle model, power type, battery type, installation location, terminal hardware level, and compensation version; the rule management module can maintain challenge_batch_ref, amplitude upper bound, duration upper bound, receipt strategy, and audit trigger strategy under different risk levels; the audit module is used to issue restricted audit requests to the terminal in dispute or sampling scenarios and perform field-level consistency verification. Detailed Implementation

[0030] Implementation Method 1: Challenge Object Construction and Challenge Strategy Selection like Figure 2 As shown, the server sends challenge objects to the vehicle terminal. The challenge object may include at least one or more of the following: challenge_id, excitation_profile_ref, band_config_ref, window reference, rule version reference, session_nonce, retry_policy_ref, amplitude_bound_ref, duration_bound_ref, and sampling_mode_ref. The server can select a suitable challenge template for the current object based on the vehicle model, terminal hardware configuration, battery status, risk level, historical stability results, and business time constraints.

[0031] In lower-risk scenarios, the server can use simplified challenge templates with short durations and low amplitudes to reduce disturbances to the vehicle's power supply network. In higher-risk scenarios, multi-round challenge_batch_refs can be used, allowing the terminal to execute different excitation_profile_ref challenges within the same session or adjacent sessions. To avoid affecting normal vehicle functionality, the server sets upper limits on amplitude_bound_ref and duration_bound_ref, and allows the terminal to refuse to execute the challenge and return a deferred_reason_ref if local operating conditions do not meet safety requirements.

[0032] Implementation Method 2: Active Response Acquisition and Active Response Object Generation like Figure 2 and Figure 3 As shown, the vehicle-mounted terminal, under the gating of a safety component, drives a controlled perturbation unit to inject a low-amplitude challenge stimulus into the vehicle's power supply network, and simultaneously acquires voltage, current, or phase-related responses within a sampling window. The stimulus does not affect normal vehicle power supply functionality and is applied only within preset amplitude and preset duration boundaries. The sampling results can be locally normalized into an active response object, which may include at least one or more of the following: frequency amplitude summary, phase summary, bandwidth energy summary, spectral peak position summary, time-domain attenuation statistical summary, response quality bitmap, noise bucketing results, and load correlation results.

[0033] The terminal can perform multiple short-term samplings under a single challenge_id, first calculating the repeated results within a local window, and then forming local candidate values ​​for repeatability_ref. For resource-constrained terminals, the terminal can also only report the summaries and quality bitmaps for each challenge, and the server can then calculate repeatability_ref uniformly. For difference comparisons under different excitation_profile_refs, the terminal can generate difference summaries for different challenge results separately, or the server can calculate separateability_ref uniformly after receiving the results.

[0034] Implementation Method 3: Compensation and Stabilization Treatment like Figure 3 As shown, the vehicle-mounted terminal performs compensation and stabilization processing on the active response object based on one or more of the following: vehicle category, temperature binning, voltage reference binning, load state binning, aging state binning, and installation location binning. The compensation can be either simple binning correction or rule-driven feature recalibration. Different `comp_ver` values ​​correspond to different sets of compensation parameters and threshold parameters, and the server and terminal maintain consistent interpretation around the same `comp_ver`.

[0035] Compensation can be divided into pre-processing compensation and post-processing compensation. Pre-processing compensation can be used for baseline normalization, noise suppression, and outlier removal of the original sampling results; post-processing compensation can be used for temperature, voltage, and aging barrel level corrections of the generated feature summary. Stabilization processing may include consistency weighting of multiple sampling results, removal of obvious outliers, and reference to nearby historical windows under the same operating conditions. The terminal or server can then generate a liveness fingerprint summary, response stability results, and challenge consistency results based on this.

[0036] Implementation Method 4: Generation and Binding Field Control of Liveness Verification Credentials After the vehicle-mounted terminal binds the liveness fingerprint digest, challenge object, window identifier, monotonic counter reference, compensation version reference, response quality bitmap, and optional repeatability_ref or their references, the security component performs integrity protection to generate a liveness verification credential. The security component only allows the output of the liveness verification credential when it detects that the controlled perturbation unit gating is effective, the sampling path is complete, the bound fields are consistent, and the counter satisfies monotonicity.

[0037] Liveness verification credentials can be further bound to one or more of terminal_profile_ref, install_position_ref, vehicle_profile_ref, or sampling_mode_ref to improve the interpretability of subsequent server verification. Before constructing credentials, the terminal can perform normalized encoding on fields, such as using a fixed field order, TLV encoding, or other deterministic serialization methods, to ensure that the server can recalculate the same digest result in audit scenarios.

[0038] Implementation Method 5: Server-Side Verification and Layering Determination like Figure 4 As shown, after receiving the liveness verification credentials, the server first verifies the integrity protection result, and then makes a judgment based on one or more of the following: challenge consistency result, historical baseline deviation result, cross-window stability result, and abnormal replay result. The server does not directly give a final conclusion based on a single distance threshold, but rather makes a joint judgment based on the following dimensions: 1. Does the response result under the current challenge_id fall within the allowable deviation range? 2. Is the repeatability of the same challenge_id sufficiently stable in recent sessions? 3. Do different excitation_profile_refs exhibit the expected structured differences? 4. Are the current comp_ver, vehicle model gear, and installation position gear compatible with the baseline set? 5. Are there any abnormal replays, window reuses, counter rollbacks, or unreasonable duplicate reporting?

[0039] If all thresholds are met, a pass result is output; if there is a slight deviation, an observation result or supplementary evidence result is output; if a serious incompatibility, replay anomaly, missing difference, or repetition collapse is hit, a rejection result or high-risk anomaly result is output. The server can map different results to different follow-up strategies, such as continuing to maintain normal evidence strength, increasing the frequency of subsequent challenges, switching challenge_batch_ref, requesting additional windows, or triggering manual review.

[0040] Implementation Method Six: Joint Determination of Repeatability of the Same Challenge and Distinguishing Between Different Challenges The server can instruct the terminal to repeatedly execute the excitation configuration corresponding to the same challenge_id within multiple session windows to obtain repeatability results for the same challenge; and switch between excitation_profile_ref or band_config_ref in different sessions to obtain distinguishability results for different challenges. If an object is stable under the same challenge but lacks sufficient distinguishable changes under different challenges, it can be determined that it is closer to a local compensation network or an equivalent simulated network than a real vehicle power supply network.

[0041] The aforementioned joint determination has clear engineering significance. Real-world vehicle power supply networks typically exhibit a structured response that is "repeatable but not entirely consistent" under the same challenges, showing differences related to wiring harness topology, load coupling, and electrical environment under different challenges. Conversely, local compensation networks or laboratory simulation networks may fit normal results under a single challenge_id using some fixed filtering or response template, but after switching challenge_batch_ref, they cannot synchronously maintain the correct difference relationship. Therefore, this invention incorporates both repeatability_ref and separateability_ref into the core determination chain.

[0042] Implementation Method Seven: Abnormal Paths, Supplementary Evidence Paths, and Delayed Execution Strategies The terminal does not immediately execute the challenge under all operating conditions. For example, during engine start-up, heavy load switching, extremely low battery levels, protection mode, or sampling chain self-test failure, the terminal can postpone execution and return `deferred_reason_ref`. The server, upon receiving this, can then issue a retry policy for the next time window, rather than directly interpreting the result as deception.

[0043] If the deviation between the current challenge_id and the historical baseline exceeds the first threshold but does not exceed the second threshold, the server can output the observation result or the supplementary verification result. If at the same time a significant deterioration in the response quality bitmap, excessive sampling noise, or a serious inconsistency between the operating conditions and the historical baseline is detected, supplementary verification will be required first. Only when the anomaly persists across multiple windows, or when there is obvious incompatibility and counter anomalies, will the process be escalated to the rejection path.

[0044] Implementation Method 8: Idempotent Deduplication, Receipts, and Audit Tracking The server can construct evidence identifiers based on one or more of the following: terminal identifier reference, challenge object reference, window identifier, and rule version reference, to perform deduplication on duplicate reports. Receipts can include at least one or more of OK, OK_DUP, REJECT, and RETRY, and may include a RejectReason or next_retry_after. This avoids duplicate reporting that pollutes statistical results due to network jitter and also allows the terminal to clearly understand subsequent actions.

[0045] For each challenge_id result, the server retains one or more of the following: challenge reference, response_ref, decision_ref, rule version reference, comp_ver, evidence identifier, and ack_code. If subsequent policy upgrades, audit checks, or dispute reviews occur, the server can replay the decision process around the same object chain without relying on temporary verbal explanations.

[0046] Implementation Method Nine: Dispute Audit and Controlled Disclosure like Figure 5 As shown, in a dispute-triggered 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, challenge_nonce, proof_type, scope_ref, and replay_ref. The vehicle terminal returns a controlled set of disclosed fields and a proof bound to the challenge_nonce according to the field mask, and the server uses this to verify the consistency between the liveness fingerprint digest and the active response object.

[0047] The `field_mask` option allows disclosure of only the minimum set of fields necessary to maintain audit coverage, such as frequency point summaries, bandwidth energy summaries, compensation version references, response quality bitmaps, or session window references, without requiring the endpoint to upload the complete raw waveform. This preserves technical verification capabilities while controlling data leakage and system load.

[0048] Implementation Method 10: Vehicle Model Adaptation and Deployment Strategy In some implementations, the server maintains different combinations of challenge_batch_ref and comp_ver based on vehicle model domain, power type, installation location, and terminal hardware level. For vehicle models with stable power supply architecture and clear load types, a stronger strategy for comparing different challenges can be adopted; for vehicle models with complex power supply architecture or frequent load fluctuations, priority can be given to enhancing the repeatability logic of the same challenge and reducing the weight of the difference between different challenges.

[0049] In some implementations, the system can be deployed in phases: the first phase collects proactive response objects in observation mode, without directly using them as strong business criteria; the second phase enables observation, supplementary verification, or rejection stratification after the baseline set stabilizes; the third phase elevates high-risk objects to strong criteria or uses them in conjunction with other authenticity strategies. Phased deployment can reduce model drift and operational pressure caused by a one-time full activation.

[0050] Implementation Method Eleven: Deploying Operating Condition Constraints and Safety Upper Bounds In some implementations, the terminal can set challenge allowance conditions based on ignition status, idling status, charging status, parking status, engine load, high-power load switching status within the vehicle, and battery state of charge. Controlled perturbations are only executed if `challenge_allow_flag` is true. If `challenge_allow_flag` is false, the terminal reports a "delayed execution" or "skip this window" status, and the server rearranges the window accordingly. This ensures that proactive challenges do not cause unacceptable impacts on the normal functioning of the vehicle.

[0051] In some implementations, `amplitude_bound_ref` and `duration_bound_ref` are issued by the server, but the terminal can impose even stricter security upper bounds locally. If the server configuration exceeds the terminal's allowed upper bound, the terminal refuses execution and logs the `reason_code`. This dual-boundary control reduces the risks associated with server misconfiguration or the issuance of abnormal templates.

[0052] Implementation Method Twelve: Identification and Deployment of Local Compensation Networks and Equivalent Simulation Networks In some implementations, local compensation networks may smooth ripple in specific frequency bands or perform delay shaping for specific load switching, making a single passive observation appear normal. Servers can improve their risk score through the following indicators: 1. The repetition is abnormally overly consistent under the same challenge_id, lacking the subtle perturbation distribution expected in a real network; 2. The differences are insufficient under different excitation_profile_refs, indicating that the adversary covers multiple challenges with a fixed template; 3. The relationship between the frequency point amplitude summary and the phase summary is incompatible with the baseline of a real vehicle model; 4. During load switching, the response quality bitmap or attenuation statistics lack the transition characteristics common in real networks.

[0053] Based on the above logic, this invention does not require the server to know the complete real network resolution model, but rather uses the structured relationships of the real network under multiple conditions to achieve identification.

[0054] Implementation Method Thirteen: Controlled Output Boundary Deployment In some implementations, the server only outputs one or more of the following status codes: pass, watch, supplementary verification, rejection, risk marker, credential reference, rule version reference, or audit reference, without outputting the complete proactive response object, complete liveness fingerprint digest, or complete challenge template in plaintext to low-privilege subjects. This satisfies business integration requirements while preventing attackers from learning the system's complete internal decision-making structure through external interfaces.

[0055] Implementation Method Fourteen: Developing in conjunction with other authenticity strategies In some implementations, this invention can be used in conjunction with existing continuous heartbeat evidence chains, passive second physical anchors, close-range mutual verification, or high-reputation third-party anchors. However, the core criterion of this invention remains the active challenge response chain constructed around challenge_id. That is, other authenticity strategies can serve as auxiliary consistency materials, tiered processing inputs, or dispute review materials, but do not replace the primary criterion status of the active challenge response object.

[0056] Implementation Method 15: Typical Deployment Example For example, in a financial leasing vehicle scenario, the server issues simplified `challenge_batch_ref`s during fixed low-risk time windows daily, and temporarily issues enhanced `challenge_batch_ref`s after high-risk events. Terminals execute the challenges without affecting normal operation, generating proactive response objects and liveness verification credentials. If a vehicle is consistently stable under the normal `challenge_id` but exhibits significant differences under the enhanced `challenge_batch_ref`, the server can mark it as a suspected local compensation network and increase the priority of subsequent manual review. This example demonstrates that the present invention can be used for both routine low-disturbance operation and event-driven enhanced verification.

[0057] Implementation Method Sixteen: Parameter Management and Version Upgrade In some implementations, the server establishes a parameter governance mechanism around `challenge_batch_ref`, `comp_ver`, rule version references, and `vehicle_profile_ref`. For each adjustment to the threshold, compensation parameters, frequency band configuration, or incentive template, the system retains the version release time, applicable vehicle model range, gray-scale activation batch, and rollback conditions. In this way, if a batch of vehicles subsequently experiences an abnormally high misjudgment rate under a specific rule version reference, the operations team can quickly pinpoint whether the issue lies with the challenge template, compensation parameters, or vehicle model compatibility.

[0058] In some implementations, terminals can also retain comp_ver compatibility information for the most recent versions locally, so that the server does not force all terminals to synchronize instantly when upgrading the challenge policy. The existence of the compatibility window helps to facilitate smooth upgrades in mass production environments, but the server should record the actual effective comp_ver and rule version references in the liveness verification credentials so that the judgment logic can be accurately replayed during subsequent audits.

[0059] Implementation Method Seventeen: Adaptation and Deployment of Manufacturing Deviations and Installation Differences In some implementations, different batches of vehicles of the same model may have slight differences in wiring harness layout, connector batches, battery brand, and terminal installation location. If the system ignores these mass production deviations, it may misjudge genuine differences as anomalies. To address this, the server can further subdivide `vehicle_profile_ref` into objects such as `harness_bucket_ref`, `battery_bucket_ref`, `install_bucket_ref`, and `hw_rev_ref`. After the terminal executes the challenge, it includes the corresponding gear reference in the liveness verification credentials, and the server uses this to reference a more refined set of baselines.

[0060] The aforementioned adaptation does not mean infinitely relaxing the threshold, but rather that it means separating the originally mixed-up real differences into more precise baseline buckets for processing. This maintains the strength of the authenticity verification while avoiding misidentifying manufactured deviations as attacks.

[0061] Implementation Method 18: Explanation of the Original Waveform Preservation Strategy In some implementations, the system does not upload the complete original waveform by default. However, in high-risk dispute scenarios, the terminal can temporarily retain a sealed reference to the original segment locally. This reference is not directly exposed to the business side; it is only allowed to extract a very small number of necessary segments through a controlled interface when a legitimate audit request arrives and the field_mask covers the corresponding scope_ref. This design helps to maintain a lightweight approach under normal circumstances while retaining stronger review capabilities in a few disputed events.

[0062] Implementation Method Nineteen: Deployment of Joint Fault Troubleshooting Mode In some implementations, when a vehicle remains under observation or supplementary certification for an extended period, the server can switch to troubleshooting mode instead of immediately classifying it as an attack. In troubleshooting mode, the risk weight of `challenge_batch_ref` can be reduced, the number of sampling windows increased, more environmental fields recorded, and prompts for installation verification or maintenance checks. If the troubleshooting reveals a stable offset caused by battery degradation, connector oxidation, or poor wiring harness contact, migration or repair can be guided; if the anomaly only occurs under enhanced challenges without environmental explanation, the risk level is increased.

[0063] Implementation Method 20: Expanding Interface Constraints with Business Systems In some implementations, the business system only receives a limited set of status codes such as PASS, OBSERVE, SUPPLEMENT, REJECT, and AUDIT_HOLD, along with necessary credential references and time window references, without directly accessing the proactive response object and challenge template details. Interface constraints prevent the business system from over-interpreting the underlying physical verification results and also prevent attackers from gradually inferring the internal structure of the challenge through the business interface.

[0064] Implementation Method 21: Challenge Template Library and Canary Release Deployment In some implementations, the server can maintain the mapping between `challenge_template_ref`, `vehicle_profile_ref`, `risk_tier_ref`, and `rollout_batch_ref`. `challenge_template_ref` not only defines `excitation_profile_ref` and `band_config_ref`, but can also further constrain the recommended sampling window length, the allowed number of retries, the terminal local upper bound, and whether to require `repeatability_ref` or `separability_ref` to be enabled. Through template library governance, the system can extract challenge strategies for different vehicle models, terminals, and risk levels from the main text logic into a versionable set of objects.

[0065] In some implementations, the new `challenge_template_ref` is not rolled out to all terminals at once, but rather gradually enabled in a small batch of objects corresponding to `rollout_batch_ref`. The server continuously monitors the false rejection rate, recertification rate, latency execution rate, and average power consumption under this template. If the new template stabilizes within multiple statistical windows, its applicability is expanded. If a significant increase in error occurs for a specific vehicle model, a quick rollback to the old template can be implemented. This gradual rollout approach allows the proactive impedance challenge strategy to continuously evolve in the mass production environment without incurring the operational risks of a one-time full rollout.

[0066] Implementation Method 22: Sampling Timing Synchronization and Local Time Base Quality Deployment In some implementations, before executing the sampling corresponding to challenge_id, the terminal can first generate local time base quality fields such as sampling_clock_quality_ref, sync_guard_ref, and local_jitter_ref to describe the synchronization state between the current sampling timer, ADC trigger chain, and controlled perturbation unit. If the time base quality is insufficient, even if challenge_allow_flag is true, the result of this round can be marked as low confidence or directly enter the delayed execution path to avoid misjudging sampling chain jitter as a power supply network anomaly.

[0067] In some implementations, the terminal can perform a short-term idle calibration, sampling chain self-check, and reference channel comparison before the challenge begins, forming a preflight_check_ref. After receiving the liveness verification credentials, the server can incorporate the preflight_check_ref along with the response quality bitmap into the decision chain. In this way, the examiner can clearly understand that the present invention does not assume that any sampling is inherently reliable, but rather explicitly provides a self-checking and filtering path under conditions of real-world hardware noise, clock skew, and sampling chain drift.

[0068] Implementation Method 23: Baseline Modeling and Aging Window Management In some implementations, the server can maintain a multi-layered set of baselines around `terminal_profile_ref`, `install_bucket_ref`, `battery_bucket_ref`, and `hw_rev_ref`. Each baseline includes not only the central characteristic but also the allowable fluctuation range, the stable interval over the past thirty days, the applicable bucket for environmental compensation, and a summary of aging trends. This allows natural aging, seasonal variations, and installation location differences to be interpreted within the same chain of objects, rather than simply treating all changes as anomalies.

[0069] In some implementations, the server can also track the response degradation trend of an object across multiple time windows around `aging_window_ref`. For example, when the frequency point amplitude summary and time-domain attenuation statistics change slowly over a longer period and are consistent with the expected change direction of `battery_bucket_ref` or `harness_bucket_ref`, the server can relax some short-term judgment weights; however, if the same object experiences a sudden change in a short period that is clearly incompatible with the aging model, the risk score is increased. This design allows the system to withstand natural drift during long-term mass production operation without relaxing the identification strength of anomalous forgery networks due to excessive tolerance.

[0070] Implementation Method 24: Terminal Self-Test Failure and Protective Degradation Deployment In some implementations, the terminal can execute `selftest_bundle_ref` in conjunction with the controlled perturbation unit, sampling circuit, reference voltage source, and security components. If any critical component fails, such as an abnormal output from the perturbation unit, ADC saturation, reference voltage drift exceeding limits, or the security component failing to complete the binding field verification, the terminal returns a state such as `SELFTEST_FAIL`, `RETRY_LATER`, or `MAINTENANCE_REQUIRED`, without generating a liveness verification credential for final determination.

[0071] In some implementations, the server should not directly interpret such self-test failures as attacks. Instead, the server can decide, based on the failure type in `selftest_bundle_ref`, whether to issue a lighter `challenge_template_ref`, postpone retrying to a low-load window, or guide the system into maintenance checks. Through this protective degradation path, the present invention can distinguish between "terminal-specific measurement chain problems" and "external spoofed network problems," thereby improving the maintainability and interpretability of the system in real-world operating environments.

[0072] Implementation Method 25: Adversarial Learning-Based Response Forgery Deployment In some implementations, attackers may observe the output pattern of a vehicle under a fixed `challenge_template_ref` over a long period and attempt to construct an approximate local compensation network or offline response lookup table. To reduce the success rate of such learned forgeries, the server can dynamically adjust the frequency band order, excitation duration binning, resampling interval, and bandwidth energy focus range within `challenge_batch_ref` while maintaining the upper security bound. For a learning adversary, even if a fixed template is partially fitted, it is difficult to maintain the correct relationship between `repeatability_ref` and `separability_ref` simultaneously under multi-round, cross-template, and cross-window conditions.

[0073] In some implementations, the server can also maintain an `anti_overfit_score` to describe whether an object excessively exhibits an "abnormally smooth and overly template-dependent" response pattern under different `challenge_template_ref` values. Real-world vehicle networks typically exhibit a certain degree of natural dispersion under different loads and environments, while lookup-based forgery is more likely to manifest as being overly regular across multiple templates. By incorporating `anti_overfit_score` into the decision chain, this invention further clarifies its suppression logic against advanced forgers, rather than remaining at the level of a single threshold detection.

[0074] Implementation Method 26: Deploying the Recalculation Path for Dispute Review In some implementations, when a dispute is triggered, the server not only outputs a simple conclusion but can also reconstruct a complete decision context based on the challenge reference, response_ref, rule version reference, comp_ver, and evidence identifier. The high-privilege auditing module can use the same set of compensation parameters, threshold parameters, and environment bucket interpretation rules as the original decision to recalculate challenge_consistency_ref, repeatability_ref, separateability_ref, and decision_ref for the same proactive response object. This proves that the server's conclusion is not a one-time black-box output but can be stably recalculated under the same version conditions.

[0075] In some implementations, if the recalculation result is significantly inconsistent with the initial determination, the system can further check for reasons such as changes to `comp_ver`, differences in field serialization, incorrect terminal field binding, or insufficient audit scope. This recalculation path is particularly important for submission for review because it demonstrates that the invention not only discloses "how to determine," but also "how to prove why that determination was made in a dispute."

[0076] Implementation Method 27: After-sales replacement parts and reinstallation adaptation In some implementations, vehicles may undergo after-sales procedures such as battery replacement, wiring harness repair, connector cleaning, terminal mounting bracket replacement, or rewiring. Such actions may affect the power network response but do not necessarily indicate spoofing. The terminal or maintenance system can generate a `maintenance_context_ref` field, including the type of replacement part, the type of mounting location change, and the time window of the work completion as supplementary descriptive fields. When the server observes changes in the challenge response, it can interpret this in conjunction with `maintenance_context_ref`, `aging_window_ref`, and the stability results of the most recent windows.

[0077] In some implementations, if stable and interpretable changes occur after maintenance, the server can enter a longer observation mode instead of directly rejecting the service; if the maintenance statement and the direction of the response change are clearly inconsistent—for example, only cleaning the connectors is stated but a large-scale pattern reconstruction similar to replacing an entire wiring harness occurs—the server can maintain a high-risk observation. Through this approach, the present invention distinguishes between legitimate after-sales changes and forged modifications disguised as maintenance, improving project feasibility.

[0078] Implementation Method 28: Manufacturing Calibration and Factory Initialization In some implementations, during initial activation or factory calibration, the terminal can perform a low-perturbation calibration challenge corresponding to `factory_init_ref` to form an initial baseline set. This initial baseline does not require all strong criterion training to be completed at once, but can be gradually improved within the first few safe windows. The terminal can record `factory_batch_ref`, `hw_rev_ref`, and `install_bucket_ref`, which the server uses to separate different manufacturing batches and installation batches into different baseline groups.

[0079] In some implementations, if sufficient quality data is not obtained during the factory initialization phase, the server can place the object in the warmup_mode_ref, outputting only the observations and not immediately enabling the rejection path. This avoids prematurely classifying new devices as abnormal due to insufficient baselines and provides a buffer for assembly differences, transportation impacts, and initial power-on jitter during mass production deployment.

[0080] Implementation Method 29: Multi-tenant Operation and Hierarchical Access Control In some implementations, the server-side system can serve different fleets, financial entities, site operators, or auditing firms. To prevent unauthorized access to the underlying physical authenticity data by these entities, the system can implement hierarchical access control based on tenant_ref, role_scope_ref, and disclosure_level_ref. Ordinary business tenants typically only read status codes and credential references, technical audit tenants can read some summary fields with proper authorization, and high-privilege platform maintenance personnel can recalculate the complete challenge decision chain.

[0081] By employing multi-tenant permission layering, this invention can adapt to complex business collaboration scenarios while ensuring that the results of proactive resistance challenges are not overused or misinterpreted by low-privilege subjects. This section further enhances the sufficiency of disclosure because it illustrates how underlying technical objects are securely exposed and reused when the system enters a multi-party collaborative environment.

[0082] Implementation Method Thirty: Statistical Monitoring and Continuous Optimization In some implementations, the server can monitor operational metrics such as false_reject_rate_ref, supplement_rate_ref, deferred_rate_ref, template_success_rate_ref, and dispute_reopen_rate_ref over a long period. If a challenge_template_ref consistently triggers a high deferred_rate_ref in a certain vehicle model domain, it can indicate that the terminal security upper bound is too strict or the window selection is unreasonable. If supplement_rate_ref rises abnormally, it can indicate that the thresholds of repeatability_ref or separation_ref need to be recalibrated. If dispute_reopen_rate_ref rises, it can indicate that the audit field design is inadequate.

[0083] In some implementations, continuous optimization of the system should not rely on arbitrary adjustments based on human experience. Instead, the impact scope and statistical results of each change should be recorded through rule version references, template_ref, and rollout_batch_ref. This provides governance traces for subsequent audits and clearly demonstrates to reviewers that the invention has a monitorable, rollbackable, and optimizable closed-loop mechanism for long-term mass production operation, rather than a one-off static solution.

[0084] Implementation Method Thirty-One: Field Serialization and Summary Reconstruction In some implementations, when constructing the active response object and liveness verification credential, the terminal can employ a fixed field order, field length constraints, and versioned dictionary mapping. For example, the frequency point amplitude digest, phase digest, and bandwidth energy digest can be arranged according to a predefined frequency band order, and the response quality bitmap and load correlation results can use fixed-length bucket encoding. After receiving the data, the server performs deserialization and consistency verification accordingly, thereby ensuring that the recalculation process under the same comp_ver is not affected by differences in field arrangement.

[0085] In some implementations, if the terminal upgrade supports more digest fields, backward compatibility can still be maintained through `optional_field_map_ref`. Older server versions can ignore unknown optional fields and continue processing the core digest, while newer server versions can utilize extended fields to improve judgment accuracy. Through this field serialization and compatibility path, this invention further discloses how to maintain audit replay capabilities over long-term version evolution.

[0086] Implementation Method 32: Selection and Priority Expansion of Supplementary Certificate Window In some implementations, when the server outputs the supplementary verification result, it doesn't simply request "retest," but instead generates a `supplement_plan_ref` based on the reason for the failure in this round. If the anomaly mainly stems from insufficient time base quality, a lower load and more stable time slot are selected; if the anomaly mainly stems from insufficient difference in challenges, a different `excitation_profile_ref` is issued; if the anomaly mainly stems from deterioration of the response quality bitmap, it is postponed to a more suitable operating condition and the challenge duration is shortened. This makes the supplementary verification process more targeted and avoids indiscriminate repeated measurements.

[0087] In some implementations, the server can also assign priorities to `supplement_plan_ref`. High-risk objects can be re-challenged in a shorter time, while low-risk objects can be placed in the next low-perturbation window. This design discloses the specific bridging logic between the failure decision and re-verification, making the technology chain more complete.

[0088] Implementation Method Thirty-Three: Adaptation to Multiple Temperature Zones and Seasonal Migration In some implementations, the power supply network impedance of the same vehicle may exhibit regular differences under conditions of high summer temperatures, low winter temperatures, and transitional seasons. The server can maintain hierarchical baselines around `season_bucket_ref` and `temp_band_ref`, allowing certain long-term interpretable differences to be considered natural variations rather than anomalies. When uploading an active response object, the terminal can simultaneously upload local temperature-divided buckets and battery thermal state summaries, enabling the server to select a more appropriate comparison path.

[0089] In some implementations, if an object consistently triggers only mild anomalies in a specific extreme temperature range while remaining stable in other temperature ranges, the server can output temperature-specific observations instead of a global rejection. Through this temperature-range adaptation mechanism, this invention provides a more comprehensive disclosure of the year-round operating conditions of real-world vehicles.

[0090] Implementation Method Thirty-Four: Abnormal Session Clustering and Black Sample Management In some implementations, the server can cluster consecutively occurring anomalies into anomaly_cluster_refs and record their corresponding challenge_template_ref, comp_ver, environment bucket, and installation bucket. If multiple different vehicles exhibit similar anomaly clusters within the same environment bucket, it may indicate a template configuration issue; if only a few vehicles form stable anomaly clusters, it is more likely to point to real risks or hardware degradation. Through anomaly_cluster_refs, the system can elevate scattered anomaly sessions into analyzable structural objects.

[0091] In some implementations, manually verified anomalous clusters can be converted into blacksample_refs for subsequent template tuning and adversarial learning-based forgery detection. Instead of directly saving the original waveform, blacksample_refs save anonymized and summarized pattern features. This supports continuous optimization without violating the principle of minimum exposure.

[0092] Implementation Method Thirty-Five: Deployment of Cross-Domain Joint Audit and Supervision Interface If multiple business domains simultaneously rely on the same liveness verification result—for example, risk control, after-sales, and audit systems all referencing a challenge conclusion—the server can generate a `cross_domain_audit_ref`. This reference is used to bind the minimum results required by different domains to the same evidence identifier, preventing each domain from copying the complete physical digest independently. High-privilege regulatory interfaces can, under legitimate conditions, pull a unified evidence view based on the `cross_domain_audit_ref` without directly accessing all underlying objects.

[0093] Through a cross-domain joint auditing interface, this invention can maintain a single, reliable source of evidence when multiple systems are collaborating, while preventing the uncontrolled spread of underlying physical authenticity data across multiple systems. This content further supplements the implementation details for real-world operational systems.

[0094] Implementation Method Thirty-Six: Deploying the Challenge of Deactivation and Freezing Strategies If a terminal profile reference repeatedly triggers high-risk anomalies, audit rejections, or hardware self-test failures, the server can add that object to a challenge suspend reference, temporarily halting the issuance of active challenges and retaining only read-only observation or manual review entry points. During the suspension period, the terminal typically no longer generates liveness verification credentials that can directly enter the normal business chain, but instead focuses on providing the minimum information required for troubleshooting or review.

[0095] This freezing strategy helps prevent clearly anomalous objects from continuously polluting the statistical baseline and also avoids attackers from repeatedly challenging the system's strategy under high-risk conditions. By introducing `challenge_suspend_ref`, this invention discloses a governance path from anomaly detection to temporarily suspending proactive verification capabilities.

[0096] Implementation Method Thirty-Seven: Multi-Phase Activation Threshold Deployment The system can maintain separate enrollment_threshold_ref, promotion_threshold_ref, and strong_enforcement_threshold_ref for the same vehicle. New objects can initially enter observation mode by meeting only the lower enrollment_threshold_ref. Only when the promotion_threshold_ref is consistently reached over a continuous window will the system allow the results of proactive challenges to be used as a key criterion. Only after long-term stable operation and uncontroversial reopening will the system be allowed to upgrade to strong_enforcement_threshold_ref, directly producing a strong handling effect on high-risk events.

[0097] This multi-stage threshold design allows active impedance spectroscopy verification to be smoothly integrated into existing business systems without having to bear the full weight of judgment logic from the outset. For examiners, this means that the invention not only "produces results," but also clearly discloses how those results gradually acquire a higher level of credibility.

[0098] Implementation Method Thirty-Eight: A Concessionary Strategy for Car Models with Scarce Samples For certain rare vehicle models, special vehicles, or terminals with low installation volumes, it may be difficult to quickly accumulate a sufficient population baseline. The server can employ a more conservative approach under `early_sparse_mode_ref`, such as increasing the proportion of supplementary evidence, reducing the frequency of strong rejection triggers, and prioritizing repeatability within the same challenge rather than cross-population comparisons. Once a sufficient sample size has been accumulated, the complete diversity and cross-object comparison logic can be gradually restored.

[0099] By specifically addressing scenarios with scarce samples, this invention avoids the limitation of being applicable only to mass-produced vehicles and further enhances its feasibility in long-tail vehicles and under special deployment conditions.

[0100] Implementation Method Thirty-Nine: Manual Confirmation of Feedback and Strategy Revision The conclusions of manual review can be fed back to form human_feedback_ref, which is then bound to challenge_template_ref, vehicle_profile_ref, and anomaly_cluster_ref. If manual review repeatedly confirms that an anomaly actually originates from real hardware degradation or mass production deviation, the server can revise the template or baseline bucket accordingly. If manual review confirms that a certain type of anomaly is indeed caused by a fake network, the corresponding pattern can be promoted to a high-priority black sample.

[0101] By objectifying and feeding back the results of manual verification, this invention achieves a closed loop from operational practice to rule optimization, rather than separating manual review from automatic judgment. This section further strengthens the specification's disclosure of the continuous improvement path under long-term operation and maintenance conditions.

[0102] Implementation Method 40: Cross-Stage Evidence Inheritance and Consistency Verification The results of proactive resistance challenges can be inherited progressively across the observation, supplementary evidence, audit, and intensive action phases, but the granularity of evidence inherited differs across phases. The observation phase inherits only the status code and minimum digest reference; the supplementary evidence phase can inherit the failure reason and recommended template; only the audit phase can inherit more granular responses, rule version references, and comp_ver bindings. The server can control the scope of evidence visible at different phases via evidence_scope_ref and perform consistency checks during phase transitions.

[0103] If discrepancies arise in field interpretations, broken version references, or mismatches between evidence identifiers and challenge references for an object between the observation and supplementary evidence phases, the system can immediately flag `phase_inconsistency_ref` and stop further promotion of the evidence level. Through this cross-phase inheritance and consistency verification design, this invention more completely discloses the logic of "how results are gradually upgraded to strong evidence," and also reduces disputes caused by imprecise phase transitions in actual deployments.

[0104] Implementation Method 41: Deploying Low-Power Long-Term Dwelling Scenarios In some implementations, certain vehicle terminals remain in a low-power dwell state for extended periods, only permitted to perform active challenges within a very limited number of windows. To address this, the server can configure `dormant_profile_ref` and employ a longer comparison window, a lower challenge frequency, and a higher level of audit conservatism. Upon each wake-up, the terminal can first upload a summary of the wake-up reason, a summary of battery state changes during the dwell period, and local self-test results before deciding whether to proceed to the `challenge_allow_flag` establishment path. If the environmental state is unstable after wake-up, only observation is performed without immediately issuing a strong conclusion.

[0105] The significance of disclosing the low-power dwell scenario lies in demonstrating that the invention does not rely on continuous high-frequency challenges to be valid. Even in mass-produced terminals where power consumption needs strict control, the invention can still maintain its verifiability assessment capability through a sparse but structured challenge window. This further enhances the practical deployability of the solution.

[0106] Implementation Method 42: Batch Recall and Strategy Convergence Deployment In some implementations, if the platform detects that a certain `hardware_batch_ref` or `harness_bucket_ref` appears in a concentrated `anomaly_cluster_ref` within a short period of time, it can trigger `batch_review_ref`. Batch review does not require immediately taking all objects offline. Instead, it can first uniformly reduce the weight of strong challenge judgments, increase the proportion of supplementary certifications, and aggregate and observe in the background whether it is related to the same installation location, the same batch of parts, or the same template update. If subsequent confirmation indicates that the problem stems from batch assembly differences or template configuration deviations, the platform can uniformly converge to the new `comp_ver`, `challenge_template_ref`, or `install_bucket_ref` boundary.

[0107] Through batch recall and strategy convergence mechanisms, this invention further demonstrates its group governance capabilities in large-scale mass production deployment. In other words, this invention can not only identify individual vehicle anomalies, but also provide feasible convergence paths when a group of similar objects experiences simultaneous fluctuations, thereby avoiding the misinterpretation of platform-level issues as independent attack events on a vehicle-by-vehicle basis.

[0108] in conclusion This invention establishes an active liveness verification technology chain for power supply networks through controlled perturbation excitation, active response summarization, compensatory stabilization processing, security component gating, joint comparison of repeatability of the same challenge and distinguishability of different challenges, and server-side layered verification. This technology chain significantly improves the ability to identify simulators, compensators, locally forged networks, and offline spoofing devices within the constraints of real-world terminal hardware capabilities, acceptable power consumption, and mass production deployment. It also provides a replayable and interpretable object-oriented evidentiary basis for subsequent auditing and dispute review.

Claims

1. A liveness verification method for on-board power supply networks based on active impedance spectroscopy challenge, characterized in that, The method, executed collaboratively by an onboard terminal and a server, includes a controlled perturbation unit, a sampling circuit, a processor, a memory, and security components. The method comprises: the server issuing a challenge object, which includes at least one or more of the following: an excitation sequence reference, a frequency band configuration reference, a sampling window reference, a rule version reference, and a session random number reference; the onboard terminal driving the controlled perturbation unit to inject a low-amplitude challenge excitation into the vehicle power supply network under the constraints of the hard-wired gating path and physical safety upper bound of the controlled perturbation unit, and simultaneously collecting one or more of the following: voltage response summary, current response summary, phase offset summary, frequency band energy distribution summary, or impulse response statistical summary, to form an active response object; and the onboard terminal, based on one or more of the following: vehicle category, temperature binning, voltage reference binning, load state binning, and aging state binning, processing the main... The dynamic response object undergoes compensation and stabilization processing, generating one or more of the following: a liveness fingerprint digest, a response stability result, and a challenge consistency result. The vehicle terminal, through a security component, performs integrity protection on one or more of the following: the liveness fingerprint digest, the challenge object, the window identifier, the monotonic counter reference, and the compensation version reference, generating a liveness verification credential and sending it to the server. The server verifies the liveness verification credential and further combines the cross-session repeatability result under the same challenge configuration with the distinguishability result under different challenge configurations. Based on one or more of the following: the challenge consistency result, the cross-window stability result, the historical baseline deviation result, and the abnormal replay result, it outputs one or more of the following verification results: pass, observe, supplementary verification, or rejection. The liveness verification credential is used to characterize the validity of the current vehicle power supply network's liveness response to the controlled challenge.

2. A liveness verification system for vehicle-mounted power supply networks based on active impedance spectroscopy challenges, characterized in that, The system includes an in-vehicle terminal and a server; wherein the in-vehicle terminal includes a controlled perturbation unit, a sampling circuit, a processor, a memory, and a security component, and the server includes a challenge issuance module, a verification module, and a baseline management 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 incentive includes at least one or more of pseudo-random binary sequence incentive, segmented frequency sweep incentive, step incentive, pulse incentive or multi-frequency composite incentive, and the server can issue challenge objects with different incentive configurations in multiple rounds within the same session or adjacent sessions based on challenge batch reference.

5. The method according to claim 1, wherein the active response object includes at least one or more of the following: amplitude summary, phase summary, bandwidth energy summary, resonant peak location summary, or time-domain attenuation constant summary of multiple frequency points.

6. The method according to claim 1, wherein the compensation and stabilization treatment includes at least one or more of temperature compensation, voltage reference compensation, battery state of charge compensation, load combination compensation, aging tank compensation, or installation position compensation.

7. The method of claim 1, wherein the security component allows the generation of the liveness verification credential only when the gating path, sampling path and challenge object binding relationship of the controlled perturbation unit are simultaneously satisfied, so as to prevent bypassing the controlled challenge process to directly forge the verification result.

8. The method according to claim 1, wherein the server constructs an idempotent key based on one or more of terminal identifier reference, challenge object reference, window identifier and rule version reference, performs deduplication on repeatedly reported liveness verification credentials and returns one or more of pass receipt, duplicate receipt or rejection receipt.

9. The method according to claim 1, wherein when the deviation of the active response object from the historical baseline exceeds a first threshold but does not exceed a second threshold, the server outputs an observation result or a supplementary verification result; when the deviation exceeds the second threshold, the server outputs a rejection result or a high-risk abnormal result.

10. The method of claim 1, wherein the server issues an audit request when a dispute is triggered, the audit request including at least one or more of an authorization token, a field mask, a challenge random number, and a proof type reference, and the vehicle terminal returns one or more of a controlled disclosure field set, a proof bound to the challenge random number, and a locally sealed original fragment reference according to the audit request, to support verification of the consistency between the liveness fingerprint digest and the active response object.

Images