PUF fingerprint uniqueness binding method and system based on power network impedance response and storage medium

Abstract

The invention discloses a hardware fingerprint scheme for unique binding of a vehicle-mounted terminal and a vehicle physical entity, and the scheme is cooperatively executed by the vehicle-mounted terminal and a server: the vehicle-mounted terminal applies a preset excitation sequence to a vehicle power network under a controlled excitation condition and collects voltage and / or current response; extracting impedance spectrum characteristics or time domain impulse response characteristics based on the response signals, and generating stable PUF fingerprints or derived keys in combination with environment compensation, aging compensation and a fuzzy extractor; the vehicle-mounted terminal triggers the security component to execute integrity protection operation on the fingerprint commitment value, the challenge random number and the window identifier to generate a PUF proof and report the PUF proof to the server, wherein the fingerprint commitment value is further bound with the monotonic counter reference information and the compensation version identifier to inhibit parameter rollback and support long-term drift processing; the server verifies the PUF attestation based on challenge-response consistency, threshold determination, and rule version reference, and permits or rejects key business credential generation accordingly. According to the scheme, an adversarial barrier is moved to a hardware-physical characteristic level from a simulatable software message, the counterfeit and simulator attack cost is remarkably improved, and the method is suitable for scenes such as high-value vehicle mortgage, financing lease and insurance risk control.

Description

Technical Field

[0001] This invention belongs to the field of trusted binding and anti-counterfeiting identification of vehicle terminal hardware, and particularly relates to a method, system and storage medium for generating, verifying and binding a Physically Unclonable Function (PUF) fingerprint based on the impedance response of the vehicle power network. Background Technology

[0002] In scenarios such as vehicle-to-everything (V2X) risk control, mortgage supervision, financial leasing, and insurance fraud prevention, it is necessary to reliably bind the data generated by the vehicle terminal to the "unique physical entity of the vehicle." Traditional environmental fingerprinting often relies on bus messages or software observable features, which are easily replicated by high-fidelity simulators: attackers can replay ECU messages, simulate sensor outputs, and even replicate the terminal software stack, thereby bypassing the "software layer consistency check."

[0003] The vehicle power network consists of wiring harness resistance, capacitance, inductance, connection point contact resistance, and load distribution. Its equivalent impedance and response characteristics are affected by manufacturing tolerances, assembly differences, and aging, exhibiting individual variations that are difficult to replicate precisely. If the impedance response characteristics of this power network can be collected and extracted under controlled excitation, and a repeatable fingerprint can be formed through a stabilization mechanism, the barrier can be shifted from software algorithms to the hardware-physical characteristics level, increasing the difficulty of counterfeiting. Summary of the Invention

[0004] (a) Purpose of the invention A PUF fingerprinting scheme based on power network impedance response is provided to achieve: 1) Challenge-response controlled stimuli and sampling to form verifiable evidence of power network response; 2) Generate stable fingerprints or derived keys through environmental compensation and fuzzy extractors; 3) The fingerprint commitment value is signed / authenticated through a security component to form a verifiable PUF proof; 4) The server completes the physical-level binding of "one vehicle, one terminal, one key" and uses it for gating of critical business credentials.

[0005] (II) Technical Solution This invention provides a PUF fingerprint uniqueness binding method based on power network impedance response, which is executed collaboratively by the vehicle terminal and the server.

[0006] In some embodiments, the end-to-end closed loop of the present invention can be summarized as "challenge issuance → controlled stimulus and synchronous sampling → impedance / feature construction → environmental compensation and stabilization → fingerprint commitment → security component proof → server threshold determination → binding and gating authorization → idempotent receipt and drift handling". To reduce the risk of replay and replacement, at least the following contexts are bound: challenge_ref / session_id / nonce (session and freshness), rule_ver (compensation / threshold / algorithm caliber), env_bin (environment bucket), and a digest of helper_data (consistency of error correction auxiliary data). The server output includes a receipt code (e.g., OK, OK_DUP, RETRY, REJECT, RE_ENROLL) and reason_vector, and upon successful completion, an authorization token auth_token can be issued to implement the "PUF pass—signing / encryption only" gating.

[0007] In some embodiments, to address the slow drift caused by long-term aging, the above-mentioned binding fields may also include: monotonic counter reference information counter_ref, aging bucket identifier age_bin, and compensation version identifier comp_ver, enabling the server to update the compensation parameters in a versioned manner without reducing the anti-rollback capability, and to incorporate the compensation caliber into the auditable link.

[0008] 1) Challenge issuance: The server issues challenge parameters to the vehicle terminal. The challenge includes at least an excitation sequence identifier, a set of frequency points or timing parameters, and is bound to a session identifier or random number.

[0009] 2) Controlled Excitation and Sampling: The on-board terminal drives the controlled excitation unit to apply an excitation sequence to the vehicle power network according to the challenge; within the sampling window, the response signal is acquired through voltage sampling circuits and / or current sampling circuits. The excitation sequence can be multi-frequency sweep, PRBS, step, or pulse, etc.

[0010] 3) Feature Extraction: The vehicle terminal preprocesses the response signal (DC removal, window function, synchronization alignment) and extracts features in the frequency or time domain to obtain the fingerprint feature vector feature_vec. Frequency domain features may include amplitude and phase, spectral peak set and harmonic structure; time domain features may include impulse response statistics or amplitude combinations at specific time delay points.

[0011] 4) Environmental Compensation and Stabilization: To reduce the impact of temperature, power supply voltage, SOC, and load variations on fingerprints, the vehicle terminal performs bucket correction according to the compensation parameter set referenced by rule_ver. Subsequently, the fuzzy extractor converts feature_vec into a stable output puf_key or puf_id, and generates auxiliary data helper_data. The fuzzy extractor may include error correction coding and hash extraction processes, and helper_data contains error correction auxiliary information such as syndrome.

[0012] 5) Fingerprint commitment and proof: The vehicle terminal constructs a puf_commitment, which binds at least challenge_ref, rule_ver, window identifier and helper_data digest; the vehicle terminal triggers the security component to perform signature or message authentication code on the puf_commitment to generate a puf_proof, and reports the puf_commitment and puf_proof to the server.

[0013] 6) Validation and Binding: After the server verifies the puf_proof, it performs a threshold judgment (such as distance measurement and stability score) based on the consistency between challenge and puf_commitment. If the judgment is successful, the terminal is bound to the vehicle physical entity and the generation of key business credentials is allowed; if the judgment fails, it is rejected and a reason code is output.

[0014] In some embodiments, the security component further derives a session key based on the puf_key and allows signing or encryption of the business payload only when the server verification is successful, thereby implementing a "PUF pass - sign / encrypt only" gating policy.

[0015] (III) Beneficial Effects Compared with the prior art, the present invention has at least the following technical effects: 1) Utilize the individual differences in the impedance response of vehicle power networks to form physical-level unclonable fingerprints, thereby increasing the cost of simulator and cloning attacks; 2) Replay suppression is achieved by binding challenge-response logic to sessions, and verification reliability is improved by combining threshold-based judgment; 3) Stable fingerprint reproduction is achieved through environmental compensation and a blur extractor, adapting to temperature and load changes; 4) When combined with security component gating, the physical binding results can be directly applied to the generation of critical business credentials, forming a security closed loop that can be implemented in engineering. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the overall structure of a PUF fingerprint system based on power network impedance response; Figure 2 This is a flowchart illustrating the method of challenge-incentive-sampling-feature extraction-proof reporting. Figure 3 A schematic diagram of the data structure for challenge parameters, fingerprint commitment values, and PUF proofs; Figure 4 A schematic diagram of the server verification, threshold determination, and gating strategy process; Figure 5 A schematic diagram of the drift re-registration and idempotency receipt processing flow; Figure 6 This is a schematic diagram of the spread spectrum frequency hopping excitation and related despreading extraction process. Detailed Implementation

[0017] 5.1 Terminology 1) challenge: Challenge parameter.

[0018] 2) feature_vec: fingerprint feature vector.

[0019] 3) fuzzy_extractor: Fuzzy extractor.

[0020] 4) helper_data: Error correction auxiliary data.

[0021] 5) puf_commitment: Fingerprint commitment value.

[0022] 6) puf_proof: PUF proof.

[0023] 7) rule_ver: Rule version identifier, used to reference compensation / threshold / error correction / algorithm caliber.

[0024] 8) counter_ref: Monotonic counter reference information used to indicate freshness and suppress rollback.

[0025] 9) age_bin: Aging bucket identifier, used to index compensation parameters related to long-term aging.

[0026] 10) comp_ver: Compensation version identifier, used to identify the version of the compensation parameter package and suppress parameter rollback.

[0027] In addition, to facilitate alignment with the field definitions used in edge-cloud interactions, nonce / challenge_ref / challenge_id, ack_code, etc., mentioned in this article can be understood as synonyms with challenge_nonce, NonceRef, AckCode, etc.; differences in the capitalization of field names do not constitute a limitation.

[0028] 11) auth_token: Authorization token or review token used to prove the source of an audit request or gate authorization.

[0029] 12) field_mask: Field mask used to indicate the set of controlled disclosure fields or the set of fields / fragments that need to be supplemented.

[0030] 13) challenge_nonce: Challenge random number or its reference information, used to bind to a controlled set of disclosure fields and suppress replay.

[0031] 14) proof_type: proof type identifier, used to indicate the type and generation scope of the review materials or proof.

[0032] 15) policy_level: Disclosure level / policy level, used to indicate the controlled disclosure intensity or gated authorization level.

[0033] 16) AckCode: A receipt code, which includes at least OK / OK_DUP and optionally REJECT / RETRY; when using REJECT, it may optionally carry the rejection reason code RejectReason, and when using RETRY, it may optionally carry the suggested retry time next_retry_after.

[0034] 5.2 Challenge Parameters and Excitation Sequence In some embodiments, the challenge includes a set of frequency points, a sweep step, and a duration; or it includes a PRBS polynomial and a code length; the challenge is bound to a session_id and a random number to prevent replay.

[0035] 5.2.1 Spread Spectrum / Frequency Hopping Excitation (Optional) In some embodiments, to reduce externally injected interference, improve immunity to electromagnetic disturbances, and take into account EMC constraints, the challenge may further include spreading or frequency hopping parameters, enabling the controlled excitation to exhibit more "wideband, correlated despreading" characteristics. For example: 1) Spread spectrum excitation: Pulse / step / sine segments are chip-modulated based on a PN sequence (e.g., determined by a PRBS polynomial and the initial phase). The terminal obtains the response characteristics through correlation despreading on the sampling side, thereby improving the suppression of narrowband injection at the same energy. 2) Frequency hopping excitation: The challenge specifies the set of frequency points and the frequency hopping table (hop plan), and binds the hop plan to rule_ver / session_id / nonce; the terminal outputs the excitation of each frequency point in a deterministic timing sequence and samples synchronously, and the server can verify the consistency of the caliber based on the hop plan; 3) Spectral shape constraint (optional): The challenge parameter can specify the duty cycle, rising edge slope, or window function parameter to make the excitation spectrum meet the preset spectral shape / bandwidth constraints, so as to reduce the risk of interference to the vehicle power network and on-board electronic system.

[0036] like Figure 6 As shown, the terminal can incorporate the spread spectrum / frequency hopping parameters (such as hop_plan, pn_seed) and session binding fields into challenge_ref, and extract features on the sampling side through relevant despreading and synchronization alignment, thereby improving the ability to resist narrowband injection and environmental disturbances while maintaining caliber verifiability.

[0037] 5.3 Impedance Response Feature Extraction In some embodiments, voltage and current samples are sampled simultaneously and impedance spectra are estimated; or only voltage ripple is collected and features such as spectral peaks and energy bandwidth are extracted to form feature_vec.

[0038] 5.4 Fuzzy Extractor and Stable Output In some embodiments, the fuzzy_extractor quantizes the feature_vec and introduces error correction coding to resist noise; the helper_data is stored or reported as a syndrome and does not reveal the valid information of the puf_key.

[0039] 5.5 Server Authentication and Gating In some embodiments, after the server verifies the signature of puf_proof, it calculates the feature distance metric according to the threshold parameter set referenced by rule_ver and determines whether it passes or fails; if it passes, it issues an authorization status that allows signing / encryption or a challenge receipt.

[0040] 5.6 Drift handling (optional) In some embodiments, when long-term aging causes fingerprint drift to exceed a threshold, a rolling re-registration strategy is adopted: multiple responses are collected within the audit window and the threshold is updated or the binding version of helper_data and puf_commitment is updated.

[0041] 5.7 Detailed Hardware Implementation of the Controlled Excitation Unit (Example 1) The key to this invention lies in applying a "repeatable, controllable, and auditable" excitation to the vehicle's power network and acquiring the corresponding voltage / current response. In some embodiments, the controlled excitation unit may employ one or more of the following structures: 1) Controllable load injection: Periodically connecting / disconnecting the load through a MOSFET array or a controllable resistor network to form a step or pulse excitation; 2) Current source injection: Use a programmable current source to output current pulses or PRBS current sequences at specified timings; 3) PWM / DAC excitation: A sine wave / sweep excitation at a specified frequency is generated by filtering the PWM signal or outputting it via a DAC. 4) Multi-frequency superposition excitation: Superimpose excitation from multiple frequency points to reduce measurement time.

[0042] In some embodiments, to avoid affecting the vehicle's power supply, the excitation amplitude is limited by safety thresholds (e.g., upper limit of current amplitude, upper limit of duty cycle, upper limit of maximum power consumption), and the power supply voltage drop and temperature rise are monitored during the excitation process. If the limits are exceeded, the process is stopped immediately and the abnormal reason code is recorded.

[0043] 5.7.1 Hardwired gating, physical continuity conditions and gating signal path (Example 1a) In some embodiments, to prevent business-side software from bypassing the "challenge-driven—controlled stimulus—synchronous sampling" constraint, the stimulus path of the controlled stimulus unit is implemented using hard-wired gating. Its gating signal path and conduction conditions are fixed at the hardware level, thereby forming an auditable "physical conduction—stimulation only" constraint point. For example: 1) Hardwired gating signal: The security component (security cell or trusted execution environment) outputs a gating enable signal SEC_GATE_EN (example name), which directly drives the analog switch / power switch of the excitation path (e.g., MOSFET gate drive, analog switch EN, or load injection switch matrix enable) via the protected gating signal path, so that the excitation path is physically disconnected when unauthorized; 2) Gating signal path constraint: The gating signal path does not pass through general-purpose GPIO or remappable peripherals that can be arbitrarily reused by the service side (exemplary expression), but connects SEC_GATE_EN to the enable terminal of the excitation switch through access control logic or dedicated interconnection, thereby reducing the bypass risk caused by "software remapping / bypass pull-high"; 3) Physical conduction conditions: In addition to being controlled by SEC_GATE_EN, the conduction of the excitation path is also subject to physical condition interlocking restrictions. The physical conditions include at least: the power supply voltage is within the safety window, overcurrent / overtemperature is not triggered, and the optional ignition / power domain state meets the measurement window requirements; in some embodiments, the anti-tamper sensor or the shell opening detection signal can also be combined as additional conduction conditions. 4) Optional timeout semantics: Gating enable uses a fixed timing window T_gate (example) with optional timeout semantics. If T_gate is exceeded, the gating is automatically revoked and the stimulus path is physically disconnected to limit the stimulus duration and constrain the attack surface. The revocation event and gating window parameters can be logged and included in audit fields or commitment binding fields (not limited).

[0044] In some embodiments, the aforementioned hardwired gating and physical connectivity conditions shift the "whether to allow stimulation" from a purely software strategy to a hardware-verifiable path, thereby reserving interfaces for subsequent ASIC / encryption accelerators or security gating modules, and providing clear hardware deterministic constraints for review.

[0045] 5.7.2 Bus ringing / echo coupling excitation (optional) In some embodiments, to further enhance the diversity of sources of "physical unclonability" and improve resistance to intermediate boxes / simulators, controlled excitations may optionally couple to the vehicle bus transceiver to form a reproducible ringing / echo response characteristic. Exemplarily: 1) Under the premise of meeting safety conditions (e.g., bus idle, arbitration non-conflict, gating allowed, and meeting the upper limit of amplitude / duration), the terminal forms a short-term standardized excitation on the bus through controlled mode switching of the transceiver, connection / disconnection of the controllable terminal resistor, or equivalent load switching. 2) The terminal acquires the transient response of the bus voltage (ringing attenuation, overshoot amplitude, characteristic delay point sampling value, etc.) through the simulated front end and performs bucketing / quantization to obtain the bus_echo_feature, which can be used as an auxiliary feature; 3) Bind the version of bus_echo_feature to challenge_ref / rule_ver and incorporate it into the commitment / proof chain (without specifying the specific binding method), so that the server can review it according to the same standard and use it as an auxiliary criterion or risk-weighted input.

[0046] 5.8 Sampling Circuit, Synchronization and Preprocessing Refinement (Example 2) In some embodiments, the voltage sampling circuit and the current sampling circuit include a sampling front-end, an anti-aliasing filter, an analog-to-digital converter (ADC), and synchronous sampling control logic.

[0047] In some embodiments, the controlled excitation unit and the sampling circuit can be integrated with the processor in the same chip (SoC) to form an on-chip analog front-end (AFE) and synchronous sampling control logic. The SoC can provide an on-chip trigger / timestamp unit for aligning the excitation timing, sampling start point and sampling window parameters at the hardware level, and writing the alignment caliber with rule_ver (and optional policy_ver) into the audit log or commitment binding field, thereby reducing the caliber deviation caused by software scheduling jitter.

[0048] In some embodiments, the SoC may further include a security component or a security isolation domain for storing the puf_key or its derived key and performing integrity protection operations on bound fields such as puf_commitment and challenge_ref; and opening the signing / encryption capability in a gating manner after the server verifies the information, thereby realizing the hardware implementation of "fingerprint verification - signing / encryption is allowed".

[0049] 5.8.1 Sampling Window and Sampling Rate In some embodiments: 1) The sampling rate Fs is selected based on the highest excitation frequency Fmax, satisfying Fs >= 2*Fmax, and leaving an oversampling margin; 2) The sampling window length T_meas is selected based on the frequency resolution Δf, satisfying T_meas >= 1 / Δf; 3) Time alignment is performed within the sampling window to ensure that voltage and current samples are acquired under the same phase reference.

[0050] 5.8.2 Synchronization Alignment and DC Removal In some embodiments, the terminal performs the following preprocessing: 1) Perform DC removal (subtract the mean or high-pass filtering) on ​​the sampled sequence; 2) Apply window functions (such as Hann / Blackman) to reduce spectral leakage; 3) Alignment is performed based on the excitation start trigger signal or PRBS synchronization sequence to eliminate sampling start jitter.

[0051] In some embodiments, the terminal performs self-calibration on the sampling link, for example by estimating the gain / phase deviation using a known reference load or an internal calibration channel, and compensating for it in subsequent impedance estimation.

[0052] 5.9 Impedance Estimation and Eigenvector Construction Refinement (Example 3) In some embodiments, the terminal estimates the impedance spectrum Z(f) from the voltage response v(t) and the current response i(t): 1) Perform FFT on v(t) and i(t) to obtain V(f) and I(f); 2) Calculate Z(fk) = V(fk) / I(fk) on the frequency point set F = {f1, f2, ...}; 3) Stabilize the amplitude and phase, for example, by taking the logarithm of the amplitude and expanding the phase.

[0053] In some embodiments, to reduce the cost of high-speed sampling and computation in discrete implementations and improve consistency, the impedance estimation and feature construction process described above can be implemented within the SoC as a dedicated impedance calculation pipeline or hardware acceleration pipeline: the pipeline includes at least window function / DC removal and alignment preprocessing, FFT or equivalent frequency domain transformation, complex division / amplitude and phase solving and stabilization, and feature extraction and quantization output; the pipeline is implemented with fixed point or controlled precision and outputs feature_vec or its summary with deterministic delay, thereby reducing cross-device caliber deviations caused by software scheduling jitter and implementation differences.

[0054] In other embodiments, if only voltage ripple can be reliably obtained while current sampling is limited, an "equivalent impedance proxy feature" can be used, for example: 1) Extract the peak position and amplitude ratio of voltage ripple under fixed excitation; 2) Extract statistical quantities such as energy bandwidth, harmonic structure, and spectral kurtosis; 3) Extract a combination of several sampling points from the time-domain impulse response.

[0055] 5.9.1 Example of the composition of the feature vector feature_vec In some embodiments, feature_vec can be obtained by concatenating the following subvectors: 1) A = [|Z(f1)|, |Z(f2)|, ..., |Z(fn)|] magnitude subvector; 2) P = [∠Z(f1), ∠Z(f2), ..., ∠Z(fn)] phase sub-vectors; 3) H = [h1, h2, ...] is the harmonic amplitude ratio or spectral peak set; 4) S = [s1, s2, ...] Stability statistics (e.g., noise variance, SNR).

[0056] In some embodiments, the feature vectors are normalized and clipped before entering the fuzz extractor to limit the impact of outliers on the error correction overhead.

[0057] 5.10 Refinement of the Environmental Compensation and Stabilization Model (Example 4) The response of the vehicle power network is affected by temperature, supply voltage, state of charge (SOC), and load variations. To ensure repeatability, this invention employs a "bucket compensation + rule versioning" approach in some embodiments: 1) Collect environmental data: env = (temp, vbatt, soc, load_state); 2) Map environmental variables to discrete buckets env_bin; 3) Compensate feature_vec based on the compensation parameter set comp_params[env_bin] referenced by rule_ver (e.g., translation, scaling, linear transformation, or principal component projection).

[0058] In some embodiments, to address the slow drift caused by long-term aging, a compensation model is further introduced into the aging barrel: 1) The security component maintains a monotonic counter and outputs counter_ref; 2) The terminal or server obtains age_bin based on the counter_ref mapping; 3) Based on rule_ver and compensation version comp_ver, referencing the aging compensation parameter age_params[age_bin], perform secondary compensation on feature_adj to obtain feature_adj2.

[0059] In some embodiments, the secondary compensation can take a linear form: feature_adj2 = (feature_adj - b_age[age_bin]) / a_age[age_bin], or a combination of projection and translation. By versioning and binding counter_ref / age_bin / comp_ver, compensation updates can be made traceable and rollback can be suppressed.

[0060] In some embodiments, the compensation model may take the following form: 1) Linear compensation: feature_adj = (feature_vec - b[env_bin]) / a[env_bin]; 2) Projection compensation: feature_adj = W[env_bin] * feature_vec; 3) Local baseline: The historical mean of the same vehicle under similar environmental conditions is used as the baseline for difference analysis.

[0061] The compensation parameter set is referenced by the rule_ver version, thereby ensuring that the terminal and the server perform compensation and judgment under the same criteria.

[0062] 5.11 Refinement of the fuzzy_extractor (Example 5) Due to measurement noise and environmental disturbances, even for the same vehicle under the same challenge, the feature_vec may exhibit slight deviations. A fuzz extractor is used to map "approximately equal" features to stable puf_key / puf_id.

[0063] 5.11.1 Quantization and Bit String Generation In some embodiments, the terminal quantizes the compensated feature_adj into a bit string b: 1) Set a quantization threshold or multi-level quantization boundary for each feature dimension; 2) Employ Gray code or multi-bit quantization to improve the information rate; 3) Concatenate the quantification results into b.

[0064] 5.11.2 Error Correction Coding and Helper Data In some embodiments, the fuzz extractor includes an error correction process: 1) Choose an error correction code (e.g., BCH, Reed-Solomon, or LDPC) and determine the code rate; 2) Generate auxiliary data (such as syndrome or verification information) during the registration phase; 3) During the verification phase, helper_data is used to correct errors in the current bit string b' and recover the stable bit string b*.

[0065] helper_data can be reported or stored, and under proper construction, it does not reveal valid information about puf_key (e.g., it meets the security property of limiting information disclosure).

[0066] 5.11.3 Hash Extraction and Identifier Generation In some embodiments, the terminal performs hash extraction on the corrected bit string to obtain: 1) puf_key = H1(b*) is used to derive the session key; 2) puf_id = H2(b*) as a fingerprint identifier.

[0067] In some embodiments, a domain-separated label and version number can be introduced for puf_key / puf_id to avoid reuse across purposes.

[0068] 5.12 Fingerprint Commitment, PUF Proof and Gating Strategy Refinement (Example 6) 5.12.1 Construction of fingerprint commitment puf_commitment In some embodiments, the terminal constructs a fingerprint commitment: 1) Calculate feature_digest = H(feature_adj); 2) Calculate helper_digest = H(helper_data); 3) Construct puf_commitment = H(feature_digest || helper_digest ||challenge_ref || rule_ver || window_id).

[0069] Here, `challenge_ref` is a summary of the challenge parameters, and `window_id` is the sampling window identifier. This binding allows the server to verify that "the commitment was indeed obtained under the specified challenge and caliber."

[0070] In some embodiments, the fingerprint commitment is further bound to aging compensation caliber and anti-rollback reference information: 1) Construct puf_commitment = H(feature_digest || helper_digest ||challenge_ref || rule_ver || window_id || counter_ref || age_bin || comp_ver); 2) Where counter_ref is the monotonic counter reference information output by the security component, and age_bin and comp_ver are used to represent the index and version of the aging compensation parameter.

[0071] Through the above binding, the server can include the "compensation version used in this measurement" into the auditable evidence chain during the verification phase, and output the failure reason code to trigger permission restriction or re-registration when a counter_ref fallback or comp_ver downgrade is detected.

[0072] 5.12.2 PUF proof (puf_proof) In some embodiments, the terminal triggers a security component to perform a signature / authentication code on the puf_commitment to obtain a puf_proof. The server uses the public key or shared key registered by the terminal to verify the puf_proof, thereby confirming that the commitment has not been tampered with.

[0073] 5.12.3 Threshold Determination and Gating In some embodiments, after the server verifies that puf_proof has passed, it performs a threshold determination: 1) Calculate the difference between the current feature_adj's distance / similarity and the registered template or historical baseline; 2) Calculate the stability score (e.g., consistency across multiple measurements, SNR, etc.); 3) Determine whether the threshold is met (the threshold is referenced by rule_ver).

[0074] If the determination is successful, the server binds the terminal to the physical vehicle entity and issues an authorization status of "allow signature / encryption"; if the determination fails, it rejects the request and outputs a reason code.

[0075] In some embodiments, the security component only allows signing or encryption of critical business loads after receiving an authorization token from the server, thus implementing a "PUF pass - sign / encryption only" gating policy.

[0076] 5.13 Idempotent receipts, retry and deduplication strategies (Example 7) To accommodate weak network conditions and retransmissions, in some embodiments, the server employs idempotent processing for challenge-response interactions.

[0077] 1) The server generates a challenge_id and binds it to a session random number; 2) When reporting, the terminal should include the challenge_id and challenge_ref. 3) The server uses req_id = H(device_id || challenge_id || rule_ver) as the idempotent key.

[0078] If a response with the same req_id arrives repeatedly, the server returns OK_DUP; if verification fails, it returns REJECT with a failure reason code (e.g., FAIL_PROOF, FAIL_DISTANCE, FAIL_SESSION, etc.); if a necessary field is missing or the rule version is unavailable, it returns RETRY and prompts the server to retrieve the corresponding rule version.

[0079] 5.14 Enrollment Phase and Template Management (Example 8) In some embodiments, PUF fingerprint binding is divided into a registration phase and a verification phase.

[0080] 5.14.1 Registration Phase Process In some embodiments, the registration phase is completed collaboratively by the server and the terminal: 1) The server issues a set of registration challenges C_enroll = {c1, c2, ...}, where each challenge contains an incentive sequence identifier, a set of frequency points, and timing parameters; 2) The terminal performs stimulation and sampling for each challenge, obtains multiple response signals, and extracts feature_vec; 3) The same challenge can be measured K times to estimate noise and stability, and the mean vector and variance vector can be obtained; 4) The terminal executes the environment compensation and fuzz extractor to generate puf_id and helper_data; 5) The terminal constructs a puf_commitment and the security component generates a puf_proof and reports it; 6) After the server verification is successful, the puf_id is bound to the vehicle identifier / terminal identifier, and the template summary and threshold parameters are stored.

[0081] In some embodiments, the registration phase may be performed under relatively stable operating conditions (e.g., engine idling and stable load) to improve template quality.

[0082] 5.14.2 Template Library and Versioning In some embodiments, the server maintains a template library `template_db`, and each template contains: 1) device_id / vehicle_id; 2) rule_ver (includes compensation parameters, quantization boundaries, error correction code configuration, and thresholds); 3) challenge_ref (challenge set summary); 4) puf_id or its digest; 5) template_stats (mean / variance / stability score summary).

[0083] When rule_ver is upgraded, a "parallel template" strategy can be adopted: during the transition period, the old template is retained and a new template is generated, and the server selects the version to accept based on the validity period and risk policy.

[0084] 5.15 Refinement of Distance Metrics, Stability Scoring, and Threshold Determination (Example 9) In some embodiments, the server's determination of "whether they are the same physical entity" is not a simple equality comparison, but is based on distance metric and stability score.

[0085] 5.15.1 Distance metric example Distance metrics can be applied to different representation spaces: 1) For a quantized bit string b, the Hamming distance d_H(b, b_ref) can be used; 2) For real-valued features, feature_adj can be represented by the weighted Euclidean distance d_E = sqrt(Σ w_i (x_i -μ_i)^2); 3) For a normalized vector, the cosine distance d_C = 1 - (x·y) / (||x|| ||y||) can be used; 4) For the impedance amplitude-phase curve, dynamic time warping (DTW) or the differential norm of the curve aligned at the frequency point can be used.

[0086] In some embodiments, the weight w_i and frequency selection are specified by rule_ver to highlight dimensions that are stable and exhibit significant individual differences.

[0087] 5.15.2 Stability Score and Freshness In some embodiments, the server calculates a stability score, such as based on the consistency of the current measurement across multiple iterations (the variance of the K challenge measurements) and the degree of deviation from historical templates. The server may also calculate freshness, for example: 1) Does the session random number match? 2) Is the challenge_id still valid? 3) Is there an abnormal repetitive response pattern (suspected replay)?

[0088] 5.15.3 Example of Judgment Rules In some embodiments, the threshold determination may employ the following combination of rules: 1) d_E <= thr_dist; 2) stability_score >= thr_stab; 3) freshness >= thr_fresh.

[0089] The thresholds mentioned above are versioned by rule_ver. If any constraint is not met, a failure reason code is output and binding or gating authorization is rejected.

[0090] 5.16 Drift Detection and Scrolling Re-registration Refinement (Example 10) Vehicle aging, wiring harness replacement, or battery replacement can cause fingerprint drift. In some embodiments, the server employs a tiered strategy to handle drift: 1) Slight drift: The distance metric increases slightly but the stability remains high, which can be mitigated by threshold adaptation or updating the compensation parameters; 2) Moderate drift: Deviation occurs on multiple challenges, requiring the terminal to re-collect and update the template under specified working conditions; 3) Severe drift: Significant inconsistency or decreased stability occurs, triggering a risk flag and suspending critical business gating.

[0091] 5.16.1 Rolling Re-registration Process In some embodiments, the rolling re-registration process includes: 1) The server issues a set of re-registration challenge criteria and sampling requirements; 2) The terminal samples from multiple environment buckets to form multiple feature_vec sets; 3) The terminal generates new helper_data_new and puf_commitment_new and has them signed by the security component; 4) During the period when the old and new templates coexist, the server uses dual thresholds to gradually migrate business bindings to the new template; 5) After the migration is complete, freeze the old template and record the migration log.

[0092] This process allows for adaptation to long-term drift without compromising safety.

[0093] 5.16.2 Aging Compensation Model and Parameter Rollback Suppression (Optional) In some embodiments, to handle long-term aging drift without frequently triggering re-registration, the server and terminal adopt a compensation update mechanism of "aging bucket + signature parameter package + anti-rollback binding".

[0094] 1) Mapping of monotonic counters to aging buckets: The security component maintains monotonic counters and provides counter_ref; the terminal or server maps them to age_bin according to the counter range, such as by the number of power-on times, by calendar period, or by the cumulative number of measurements.

[0095] 2) Signature compensation parameter package: The server publishes a compensation parameter package comp_pack, which contains at least comp_ver, the applicable counter range, age_params, and parameter digest param_ref. The server performs a signature or authentication code generation, and the terminal verifies the signature before application.

[0096] 3) Anti-rollback strategy: The terminal maintains a record of the maximum accepted comp_ver or the maximum upper bound of the counter; when it receives a parameter packet with a lower version or a counter range that does not cover the current counter_ref, the terminal refuses to apply it and sends a failure reason code to the server for handling in the report.

[0097] 4) Proof and commitment binding: When constructing puf_commitment, the terminal binds counter_ref / age_bin / comp_ver, and the security component generates puf_proof by signing the commitment; after the server verifies that puf_proof is passed, it checks the monotonicity of counter_ref and the validity of comp_ver, thereby achieving auditable and non-rollbackable compensation caliber.

[0098] Through the above mechanism, the system can maintain its rollback capability while gradually updating the compensation model to adapt to the slow drift caused by long-term aging and reduce the impact of frequent re-registration on the business experience.

[0099] 5.17 Security and Countermeasure Analysis (Example 11) In some embodiments, this invention is designed to counter the following attacks: 1) Replay Attack: Attackers replay old challenges / responses. The success rate of replay attacks can be reduced through session binding, idempotent deduplication, and challenge expiration control. 2) Simulator cloning: Attackers use software or hardware to simulate the power network response. Since impedance response is formed by wiring harness distribution, contact resistance, and load coupling, accurate simulation requires complex analog circuitry and real-time control, significantly increasing costs. 3) Man-in-the-middle tampering: An attacker tampers with the reported data. Tampering can be detected by signing the puf_commitment with a security component and verifying the signature on the server. 4) Environmental Manipulation: Attackers attempt to disrupt characteristics by changing load or temperature. Through environmental bucketing compensation and stability scoring, abnormal environmental changes can be mapped to low stability and rejected. 5) Side-channel and auxiliary data leakage: Attackers attempt to infer the puf_key from helper_data. In some embodiments, helper_data is only auxiliary information such as error correction syndrome, and is properly constructed to prevent the leakage of valid key information.

[0100] 5.18 Numerical Implementation Example: Multi-frequency sweep + Impedance spectral fingerprinting (Example 12) In some embodiments, the challenge is to employ multi-frequency sweeping: 1) Frequency set F = {1kHz, 2kHz, 5kHz, 10kHz, 20kHz}; 2) Duration of each frequency point: t_hold = 20ms; 3) Sampling rate Fs = 200kS / s; 4) The total duration of the measurement window is approximately T_meas = len(F)*t_hold = 100ms.

[0101] After acquiring v(t) and i(t), the terminal calculates Z(fk) for each frequency point, extracts the amplitude and phase, and performs compensation to form feature_vec = [|Z(f1)|, ∠Z(f1), ..., |Z(fn)|, ∠Z(fn)]. Quantization and error correction are then performed to obtain puf_id.

[0102] In some embodiments, the server uses a weighted Euclidean distance and threshold to determine the frequency, for example, assigning higher weight to low-frequency points to reflect differences in wire harness and contact resistance, and assigning medium weight to high-frequency points to reflect differences in parasitic inductance and capacitance.

[0103] 5.19 Multiple Challenges and Randomization Strategies (Example 13) In some embodiments, to further enhance anti-counterfeiting capabilities, the server does not fix a single challenge, but randomly selects challenges from a challenge pool: 1) Sets of different frequency points and frequency sweeping order; 2) Different PRBS polynomials and code lengths; 3) Different excitation amplitudes and duty cycles (within a safe range).

[0104] The terminal binds `challenge_ref` to the response, and the server verifies challenge consistency based on `challenge_id`. By combining multiple challenges, it becomes difficult for attackers to perform offline fitting for a specific fixed challenge.

[0105] 5.20 Closed-loop integration with the generation of key business vouchers (Example 14) In some embodiments, the PUF verification result is used to generate gated critical business credentials, for example: 1) The security component only allows signing of business requests if the server returns OK and the authorization token is valid; 2) If a REJECT response is returned or the authorization token expires, the business request cannot be signed, thereby blocking the critical business activities of the counterfeit terminal at the link layer; 3) The authorization token can include rule_ver and validity period, which allows the server to tighten or loosen the gating according to the policy.

[0106] Through the aforementioned closed loop, physical fingerprint binding can directly impact business security boundaries, forming a practical anti-counterfeiting system.

[0107] 5.21 Example of Interface Protocol and Data Structure Definition (Example 15) To enhance interoperability and audit traceability, in some embodiments, challenges, responses, features, and credentials are represented in a structured data format.

[0108] 5.21.1 Example of fields for the challenge parameter In some embodiments, the challenge includes at least one or more of the following fields: The server signs or authenticates the challenge, which is then executed after terminal verification to prevent man-in-the-middle substitution of challenge parameters.

[0109] 5.21.2 Example of response fields In some embodiments, when reporting a response, the terminal does not need to upload the original waveform; it can upload summary-level features and commitment fields instead. In some embodiments, feature_digest and helper_digest are used to protect privacy and compress bandwidth, while the complete feature_vec / helper_data can be retransmitted on an authorized basis in dispute or re-registration scenarios.

[0110] 5.21.3 Failure Reason Codes and Example of reason_code In some embodiments, the failure reason code returned by the server may include: 1) FAIL_SESSION: Session binding failed or expired; 2) FAIL_PROOF: puf_proof verification failed; 3) FAIL_RULEVER: rule_ver is unrecognized or expired; 4) FAIL_DISTANCE: Distance metric exceeds threshold; 5) FAIL_STABILITY: Insufficient stability score; 6) FAIL_SAFETY: The stimulus or sampling triggers the safety protection.

[0111] Reason codes can be used for automated operation and maintenance, risk identification, and guiding re-registration.

[0112] 5.22 Terminal-side state machine and implementation details (Example 16) In some embodiments, the terminal side is implemented as a state machine: 1) IDLE: Waiting for the challenge; 2) VERIFY_CHALLENGE: Verifies the server signature and its validity period; 3) MEASURE: Performs excitation and sampling to obtain the response signal; 4) EXTRACT: Preprocessing, impedance estimation, feature construction and compensation; 5) FUZZY: Quantization, error correction, and hash extraction to generate puf_id / puf_key and helper_data; 6) COMMIT: Constructs a puf_commitment and calls the security component to generate a puf_proof; 7) REPORT: Report and wait for server response; 8) GATED_OK: Allows business signing / encryption upon receiving the authorization token; 9) GATED_REJECT: If rejected, proceed to permission restriction / alarm or retry.

[0113] 5.22.1 Multiple Measurements and Consistency Screening In some embodiments, to improve stability, the terminal repeats the measurement of the same challenge K times (e.g., K=3 or 5) and performs consistency screening on the features: 1) If the noise in a measurement is too high (e.g., the SNR is below the threshold), discard that result; 2) Take the median or robust average of the remaining measurements as feature_vec; 3) Use the repeatability consistency metric as input to stability_score.

[0114] This mechanism can reduce misjudgments caused by instantaneous load fluctuations or sampling jitter.

[0115] 5.22.2 Security Protection and Degradation In some embodiments, the terminal monitors for power supply voltage drops and current anomalies in MEASURE state. If a safety threshold is triggered, the excitation is immediately stopped and the system returns to FAIL_SAFETY, while internal diagnostic information is recorded for maintenance purposes.

[0116] 5.23 Server-side state machine and implementation details (Example 17) In some embodiments, the server side is also implemented as a state machine: 1) ISSUE_CHALLENGE: Generates a challenge and records challenge_id / session_id / expire_ts; 2) RECV_RESPONSE: Receives the terminal response and verifies the integrity of the fields; 3) VERIFY_PROOF: Verifies puf_proof; 4) MATCH: Perform distance measurement and stability / freshness determination; 5) BIND: Bind or update the binding status; 6) ISSUE_TOKEN: Issue a gate authorization token; 7) LOG: Write to the audit log and risk label.

[0117] 5.23.1 Idempotency and Retry In some embodiments, the server returns OK_DUP for repeated responses to the same req_id, and returns the same authorization result or the same rejection reason code, thereby avoiding inconsistencies in state caused by retransmission in a weak network.

[0118] 5.23.2 Risk Classification In some embodiments, the server categorizes failure reasons: 1) FAIL_DISTANCE: This may be due to cloning or vehicle replacement, increasing the risk level and triggering re-registration; 2) FAIL_STABILITY: This may be due to environmental noise or poor sampling quality. It is recommended to retry or retest under specified operating conditions. 3) FAIL_PROOF: This may indicate tampering or an abnormal security component, directly leading to high risk and restricted privileges.

[0119] 5.24 Supplementary information on error sources, calibration, and compensation strategies (Example 18) In some embodiments, fingerprint stability is affected by the following sources of error: 1) ADC quantization noise and sampling jitter; 2) Excitation amplitude and duty cycle error; 3) Changes in the operating point of the power network due to temperature drift, SOC changes, and load switching; 4) Phase delay or gain error in current sampling.

[0120] To reduce errors, the present invention employs a combined calibration strategy in some embodiments: 1) Terminal factory calibration: Measure and estimate gain / phase compensation parameters under known reference load; 2) Online self-calibration: Insert "no-load segment" or "baseline segment" before and after each measurement to estimate the instantaneous noise level; 3) Frequency selection optimization: Eliminate frequencies that are extremely sensitive to the environment and retain a subset of frequencies that are highly distinguishable and stable; 4) Adaptive weights: Adjust the distance metric weights based on the environment bucket or stability score.

[0121] 5.25 Scenario-based Implementation Examples and Deployment Methods (Example 19) In some embodiments, the present invention can be used in the following scenarios: 1) Supervision of financial leasing / mortgage: It requires that "the terminal is indeed on the designated vehicle", otherwise key reports or key instructions will be rejected; 2) Insurance fraud prevention: Using physical fingerprints to prevent mass forgery of vehicle data by simulators; 3) Anti-counterfeiting of equipment: Physical layer differentiation of counterfeit terminals makes it difficult for software clones to pass through the gate control; 4) Risk audit: Increase the frequency of challenges or use stronger challenge sets for abnormal areas / abnormal terminals.

[0122] In some embodiments, challenges can be triggered at critical business moments (e.g., fund settlement, critical configuration distribution, risk control spot checks) or periodically (e.g., once a day) to balance security and power consumption.

[0123] 5.26 Modified Embodiment (Example 20) Without departing from the spirit of this invention, the following modifications can also be made: 1) Fingerprints of physical responses (e.g., ground loops, specific branch load networks) extending from the power network to other vehicular networks; 2) Expand the construction of feature_vec from impedance amplitude and phase to joint time-frequency features (e.g., wavelet coefficient energy distribution). 3) Employ multi-level gating: Low-risk transactions only require passing a weak threshold, while high-risk transactions require passing a strong threshold or passing multiple challenges consistently. 4) Combine puf_id with other trusted evidence (such as secure boot metrics, firmware version) to improve overall anti-attack capability.

[0124] The above embodiments further demonstrate that the present invention can achieve a repeatable, verifiable binding, and gated physical fingerprint closed loop in engineering.

[0125] 5.27 Example of rule_ver parameter set and threshold configuration (Example 21) In some embodiments, the server and the terminal share a parameter set referenced by the rule_ver version. The parameter set may include configurations such as excitation, sampling, features, error correction, and thresholds, enabling different batches of terminals and different software versions to complete verification under the same criteria. In some embodiments, the parameter set is referenced in the manner of param_ref = H(param_bytes). The terminal carries param_ref in the report, and the server parses the threshold and configuration accordingly, thereby achieving traceability and auditability.

[0126] 5.28 Error Correction Capability, Information Rate, and Helper_Data Security Supplement (Example 22) In some embodiments, the fuzz extractor needs to balance between “stable reproducibility” and “limited information leakage”.

[0127] 5.28.1 Error Correction Capability and Error Model In some embodiments, the terminal models the sources of bit string errors, for example, treating each quantized bit as transmitted via a binary symmetric channel (BSC), with the bit error rate related to the environmental bucket and load state. The error correction code parameter t (the number of bits that can be corrected) is selected based on the upper bound of the bit error rate, thereby ensuring that a stable bit string can be recovered within the allowable noise range.

[0128] 5.28.2 Information disclosure of helper_data is limited. In some embodiments, helper_data is a syndrome or verification information, which is not equivalent to puf_key, and with proper construction, information disclosure to puf_key can be limited to an acceptable level. For example: 1) By selecting an appropriate bitrate, the syndrome length is made much smaller than the original feature entropy; 2) By performing field separation and secondary hash extraction on puf_key, it is difficult to recover puf_key even if the syndrome is leaked; 3) Upload helper_data only during registration / re-registration, and only upload helper_digest during the verification phase to reduce the exposure surface.

[0129] 5.28.3 Information Rate and Number of Challenges In some embodiments, to improve the overall recognition rate, entropy can be increased by increasing the number of challenges or increasing the feature dimensions, while noise can be suppressed through error correction and stability screening. Servers can be selected according to risk strategies. 1) Low-risk operations: Single challenge verification is sufficient; 2) High-risk business: requires multiple challenges to pass unanimously (e.g., 2 / 3 or 3 / 5 pass).

[0130] 5.29 Supplement to the analysis of uniqueness, stability and distinguishability (Example 23) In some embodiments, the individual differences in vehicle power networks mainly stem from: 1) Differences in distributed resistance and parasitic inductance introduced by differences in wire harness length and wire diameter; 2) Differences in connector contact resistance and solder joints; 3) Differences in load distribution and loop topology; 4) Parameter drift caused by manufacturing tolerances and aging.

[0131] These differences, when superimposed, result in a difference in response that is observable in both the frequency and time domains. To verify distinguishability, in some embodiments, it can be evaluated in the following ways: 1) Statistical analysis of the distance distribution between different vehicles (inter-class distance); 2) Statistical analysis of the distance distribution of the same vehicle at different times / under different environments (intra-class distance); 3) Select a threshold to separate the two distributions as much as possible, thereby achieving a balance between false rejection (FRR) and false acceptance (FAR).

[0132] 5.30 Supplementary Case Studies and Mitigation Measures (Example 24) In some instances, attackers may attempt the following countermeasures: 1) External Analog Network: An external RLC network is connected to the terminal power input to simulate the impedance response. To mitigate this challenge, the server can randomize the challenge and use combinations of multiple frequency points and different timing sequences, making it difficult for the external network to match under all challenges. 2) Record-Playback: The attacker records a feature_digest of a measurement and plays it back. The success rate of replay can be reduced by using session binding with the challenge_id expiration date and idempotent deduplication of the req_id. 3) Manipulated Environment Bucket: Attackers artificially load loads to alter responses to approximate a template. Stability scoring and multi-challenge consistency checks can reduce the effectiveness of a single instance of environment manipulation.

[0133] 5.31 Dispute Evidence Collection and Authorized Supplementary Transmission Mechanism (Example 25, Optional) In some embodiments, to support disputed evidence collection when sensitive data is not uploaded regularly, an "authorized re-upload" mechanism can be designed: 1) For routine verification, only feature_digest / helper_digest / puf_commitment / puf_proof are uploaded; 2) When the server risk engine triggers a review, it issues an audit request carrying an authorization token (auth_token), a field mask (field_mask), a challenge nonce (challenge_nonce), and a proof type identifier (proof_type); the server receipt may optionally carry an ack_code and a suggested retry time (next_retry_after). 3) When the terminal holds a valid auth_token, it only outputs the controlled disclosure field set according to field_mask, such as uploading a de-identified feature_vec subset or uploading the amplitude and phase values ​​of several frequency points, and binds the controlled disclosure field set with challenge_nonce to generate the corresponding proof; 4) The server verifies the consistency between the controlled disclosure field set and the historical puf_commitment, and makes further risk assessments accordingly.

[0134] In other embodiments, sampling retransmission can be used: the server samples several points from the challenge / frequency point set and requests the terminal to retransmit them, thereby reducing the amount of retransmission and increasing the cost of countermeasures.

[0135] 5.32 Compliance and Data Minimization Supplement (Example 26) In some embodiments, to meet the principle of data minimization, the server only stores the necessary template summary and threshold parameters, and does not store the original waveform v(t) / i(t). The terminal can cache the waveform for a short period for self-checking and re-registration, and automatically delete it after the expiration period or only retain the summary. By converging "physical verification" into a summary-level evidence chain, anti-counterfeiting capabilities can be improved while reducing privacy and compliance risks.

[0136] 5.33 Numerical Implementation Example: PRBS Excitation and Temporal Fingerprint (Example 27) In some embodiments, the challenge employs pseudo-random binary sequence (PRBS) excitation to obtain time-domain impulse response characteristics. An example process is as follows: 1) The server sends seq_id=PRBS_07, which contains the polynomial and code length, for example, the length L=2^m-1; 2) The terminal outputs the PRBS current excitation or load switching sequence at a fixed sampling rate Fs to obtain the input u(t); 3) The terminal acquires the voltage response v(t) and current response i(t), and estimates the equivalent impulse response h(t) based on the system identification method; 4) The terminal extracts several statistics of h(t) as features, for example: - Peak amplitude and peak position; - Specifies the set of amplitude values ​​at the specified time delay points; - The slope of the energy decay curve; - Autocorrelation / cross-correlation peak and width.

[0137] In some embodiments, the terminal normalizes h(t) to reduce the impact of excitation amplitude error and prunes the features before entering the fuzz extractor to avoid error correction burden caused by extreme outliers.

[0138] 5.34 Numerical Implementation Example: Environmental Bucket Compensation and Stabilization (Example 28) In some embodiments, the environmental bins can be divided into two-dimensional bins based on temperature and voltage, for example: 1) Temperature chamber: [-20,0), [0,20), [20,40), [40,60); 2) Voltage bucket: [11.0,11.8), [11.8,12.6), [12.6,13.8).

[0139] For each `env_bin`, the server calculates the feature mean μ[env_bin] and scale σ[env_bin] for that bucket during the registration phase and sends them to the terminal as compensation parameters. The terminal compensates during the verification phase as follows: 1) feature_adj = (feature_vec - μ[env_bin]) / max(σ[env_bin], σ_min); 2) Use the compensated features for quantization and distance determination.

[0140] In some embodiments, when the environment bucket in the verification phase is inconsistent with the bucket in the registration phase, the server may require the terminal to switch to a specified operating condition for re-measurement, or adopt a cross-bucket mapping strategy (such as nearest neighbor bucket interpolation) to reduce false rejections.

[0141] 5.35 Threshold calibration method and FAR / FRR trade-off (Example 29) The core of threshold determination lies in selecting appropriate thr_dist / thr_stab / thr_fresh. In some embodiments, the server performs calibration on the sample set: 1) Collect multiple measurements of the same vehicle to obtain the intra-class distance distribution; 2) Collect measurements from different vehicles to obtain the inter-class distance distribution; 3) Choose a threshold that minimizes the false rejection rate (FRR) under the target false acceptance rate (FAR), or choose a threshold that maximizes the separation between the two distributions.

[0142] In some embodiments, the threshold can be grouped and calibrated by terminal model, hardware version, and vehicle type, and distributed via rule_ver. For high-risk operations, stricter thresholds or requirements for multiple challenges to pass consistently can be used to further reduce FAR.

[0143] 5.36 Batch Challenges, Performance and Power Consumption Estimation (Example 30) In some embodiments, to balance security and power consumption, a combined strategy of "batch challenge + low-frequency spot checks" can be adopted: 1) Daily Mode: One challenge is triggered each day or every key business operation; 2) Risk Spot Check Mode: Triggers 3-5 challenges when the risk increases, requiring a majority to pass; 3) Registration / Re-registration mode: Perform more challenges under stable operating conditions to improve template quality.

[0144] In some embodiments, the computational complexity on the terminal side primarily comes from FFT and feature construction. To reduce power consumption: 1) Select a smaller but highly discriminative set of frequency points; 2) Use fixed-point FFT or hardware acceleration; 3) After excitation and sampling are completed, quickly enter a low-power state and execute subsequent processing in a time-sharing manner.

[0145] The main server-side overhead comes from distance calculation and template retrieval. Since the uploaded features are at the summary level, the server can index and cache the templates and process them in parallel under multiple challenges, thus meeting high concurrency requirements.

[0146] 5.37 Authorization Token Format and Gating Refinement (Example 31) In some embodiments, the server issues an authorization token (auth_token) to the terminal, with the following example of its fields: 1) token_id: Token identifier; 2) device_id and vehicle_id (or their digest); 3) rule_ver and challenge_ref; 4) Scope: The permitted business scope (e.g., only allowing the signing of certain types of business messages); 5) exp_ts: Expiration time; 6) sig_server: Server signature.

[0147] Before performing signing / encryption, the endpoint security component verifies the signature and validity period of the auth_token and checks whether the scope matches the current business request, thereby avoiding the risk of "long-term abuse after verification".

[0148] 5.38 Log Traceability and Auditing Example (Example 32) In some embodiments, the server generates an audit log entry puf_audit_log for each physical verification, which includes at least: 1) EvidenceId (such as req_id), challenge_id / session_id; 2) device_id, rule_ver, env_bin; 3) Verification results of puf_commitment and puf_proof; 4) Distance metrics and stability scores; 5) Result codes OK / OK_DUP / REJECT and reason codes; 6) Whether to issue an auth_token and token digest.

[0149] The terminal side can also record simplified logs (excluding sensitive waveforms), such as challenge_id, measurement success / failure, and security protection trigger status. These dual-side logs allow for cross-validation during dispute or attack analysis.

[0150] Through the above supplementary embodiments, the present invention can realize power network impedance PUF fingerprint binding in an auditable, gated, and upgradeable manner in actual vehicle networking systems.

[0151] 5.39 Complete Process Example of End-to-End Binding Closed Loop (Example 33) The following is an example of an end-to-end binding closed loop, which illustrates the details of the entire chain from "server initiating challenge - terminal measurement - server judgment - gating service".

[0152] 5.39.1 Server initiates challenge In some embodiments, the server initiates a challenge at critical business moments (such as fund settlement, critical configuration distribution, or anomaly checks): 1) Generate challenge_id and session_id, and set exp_ts = now + 60s; 2) Select seq_id and freq_set from the challenge pool, and set Fs / fft_len / t_hold according to the terminal's capabilities; 3) Add rule_ver and param_ref (if used) to the challenge; 4) Sign and distribute the challenge.

[0153] 5.39.2 Terminal Execution Measurement and Commitment Generation In some embodiments, the terminal executes the following upon receiving the challenge: 1) Verify the signature and validity period; if it fails, reject the application and record the reason code. 2) Enter the measurement window, execute the excitation output and synchronously sample v(t) / i(t); 3) Preprocessing (DC removal, window function, synchronization alignment) and impedance estimation to generate feature_vec; 4) Calculate env_bin based on env, and compensate according to rule_ver to obtain feature_adj; 5) Quantize and correct errors to obtain a stable bit string b* and generate puf_id / puf_key and helper_data; 6) Calculate feature_digest / helper_digest and construct puf_commitment; 7) Invoke the security component to sign the puf_commitment and generate a puf_proof; 8) Report response messages (summary-level fields).

[0154] In some embodiments, the terminal may choose a two-stage strategy of "first reporting the summary, then supplementing as needed": first upload puf_commitment / puf_proof to obtain an acceptance receipt, and then upload auxiliary fields such as feature_digest / env_bin to adapt to weak networks.

[0155] 5.39.3 Server Authentication and Gating Authorization In some embodiments, the server executes the following upon receiving the response: 1) Verify the challenge_id / session_id and its validity period to check for duplicate requests; 2) Verify puf_proof to ensure the commitment has not been tampered with; 3) Execution threshold determination: distance metric, stability score, and freshness check; 4) If successful, update the binding status (or maintain the binding) and generate an auth_token; 5) If it fails, return REJECT with a reason code / reason vector summary.

[0156] 5.39.4 Business-side gating In some embodiments, before initiating a critical business request, the terminal's business module checks whether the auth_token exists and has not expired, and the security component verifies the auth_token. Only when the verification passes will the security component allow the business message to be signed / encrypted, so that even if a counterfeit terminal can construct upper-layer messages, it will not be able to obtain a valid signature and thus will not be able to pass the server's verification.

[0157] 5.40 Example of Challenge Pool Generation and Scheduling Strategy (Example 34) In some embodiments, the server maintains a challenge pool (challenge_pool) and performs tiered scheduling of challenges: 1) Basic challenges: a small number of frequency points, a short measurement window, and low power consumption, for routine spot checks; 2) High-risk: More frequency points or PRBS, higher number of repeated measurements, used for high-risk services or high-risk terminals; 3) Diagnostic challenges: Used for drift diagnosis or re-registration, including specific frequency points / timing to enhance differentiation.

[0158] The challenge pool can be generated as follows: 1) Sample a subset F_sub from the entire set of frequency points F_all; 2) Randomized frequency sweep order and dwell time (within measurable range); 3) Randomly select the polynomial and code length for the PRBS challenge.

[0159] In some embodiments, each challenge in the challenge pool is bound to rule_ver, thereby ensuring that the compensation, threshold, and error correction parameters are consistent with the challenge.

[0160] 5.41 Template Database Fields and Index Examples (Example 35) In some embodiments, the template database on the server side may contain the following fields and indexes to support high-concurrency verification and fast location: 1) Primary key: (device_id, rule_ver); 2) vehicle_id or its digest; 3) challenge_ref_set_digest: Registers a digest of the challenge set; 4) template_digest: Template summary (e.g., a summary of feature mean and scale); 5) thr_dist / thr_stab: Threshold (or threshold reference); 6) last_ok_ts / last_fail_ts: Last successful / failed time; 7) drift_score: drift score; 8) risk_level: Risk level; 9) audit_log_ref: Audit log index.

[0161] Using the above fields, the server can quickly cluster abnormal terminals, for example, filtering terminals with "gradually increasing distance and decreasing stability" for early re-registration.

[0162] 5.42 Example of handling component replacement and drift scenarios (Example 36) In actual vehicle use, battery replacements, wiring harness repairs, and equipment installations may occur, causing changes in the power network impedance. In some embodiments, the server distinguishes between these scenarios: 1) If the distance metric suddenly jumps and remains unstable in the short term, and multiple challenges fail, it is judged as high risk (possibly due to vehicle replacement or cloning), and enters strict gate control and requires offline verification. 2) If the distance metric changes gradually but remains relatively stable, it is more likely to be aging drift, allowing the process to proceed to re-registration. 3) If the test fails only in a specific environment bucket, it may be due to environmental interference. It is recommended to switch to the specified operating condition and retest.

[0163] In some embodiments, re-registration may require the terminal to collect data multiple times under the same challenge and bind helper_data_new and rule_ver_new to the new commitment, thereby preventing attackers from bypassing the gating by exploiting re-registration.

[0164] 5.43 High-fidelity attack scenario and example of multi-challenge consistency (Example 37) In some embodiments, an attacker attempts to construct an external simulated network to fit the impedance response under a fixed challenge. To improve resistance, the server can employ multi-challenge consistency: 1) Issue multiple challenges c1, c2, and c3 consecutively within a single verification session; 2) At least m challenges must be passed (e.g., 2 / 3 or 3 / 3); 3) Perform joint determination on the distance metric of each challenge output, such as weighted sum or maximum value constraint.

[0165] Since external networks have difficulty fitting different frequency sets and different timing combinations at the same time, the above strategy can significantly increase the cost of high-fidelity simulation.

[0166] 5.44 Quality Thresholds, Self-Inspection, and Recoverability Strategies (Example 38) In some embodiments, to avoid false rejections due to noise, the terminal introduces a quality threshold and self-test: 1) If the voltage drop is too large or the noise is too high within the sampling window, the current measurement will be marked as LOW_QUALITY and a retry will be requested. 2) If the SNR of the FFT result is lower than the threshold at the key frequency point, discard the measurement and resample; 3) If the quality is insufficient multiple times in a row, enter diagnostic mode and report a diagnostic summary.

[0167] When the server receives the LOW_QUALITY flag, it can return RETRY and prompt the user to retest under specified operating conditions (such as stable idling speed or shutting down high-power loads).

[0168] 5.45 Example of Modular Implementation of Terminal Firmware (Example 39) In some embodiments, the terminal firmware can be divided into modules: 1) ChallengeVerifier: Challenge verification and validity check; 2) StimulusDriver: Controlled excitation output and safety protection; 3) Sampler: Simultaneous sampling and preprocessing; 4) Impedance Estimator: FFT / impedance estimation; 5) FeatureBuilder: Feature construction and normalization; 6) Compensator: Environmental bucket compensation; 7) FuzzyExtractor: Quantization, error correction, and hash extraction; 8) CommitmentBuilder: Commitment Builder; 9) SecureEnclave: Security component interface, outputs puf_proof and performs gating; 10) Reporter: Reporting and idempotent retransmission.

[0169] By implementing modularly, the measurement link can be decoupled from the business link, and the change surface can be minimized during rule_ver iteration.

[0170] 5.46 Example of a pseudo-process for terminal-side computation (Example 40) To further illustrate the implementation details, in some embodiments, the terminal side can be implemented according to the following pseudo-flow: 1) VerifyChallenge(challenge): Verifies the server signature, validity period, and rule_ver; 2) Measure (challenge): - Configure incentives: StimulusDriver.Configure(seq_id, amp, duty, t_hold); - Configure sampling: Sampler.Configure(Fs, T_meas); - Trigger measurement and acquire v(t), i(t); 3) Preprocess(v,i): DC removal, window function, synchronization alignment, optional filtering; 4) EstimateZ(v,i): FFT obtains V(f) and I(f), and Z(f) is computed on freq_set; 5) BuildFeature(Z): Constructs features such as amplitude, phase, and spectral peaks; 6) Compensate(feature, env_bin, rule_ver): output feature_adj; 7) Quantize(feature_adj, rule_ver): Outputs the bit string b' and quality statistics; 8) Decode(b', helper_data): Corrects errors to get b*. If correction fails, outputs FAIL_STABILITY. 9) Derive(puf_key, puf_id): puf_key=H1(b), puf_id=H2(b); 10) Commit(): - feature_digest=H(feature_adj), helper_digest=H(helper_data); - puf_commitment=H(feature_digest||helper_digest||challenge_ref||rule_ver||window_id); 11) puf_proof = SecureEnclave.Sign(puf_commitment); 12) Report(puf_commitment, puf_proof, digests, env_bin, stability_score).

[0171] In some embodiments, if a safety threshold (voltage drop / temperature rise / overcurrent) is triggered during the Measure() process, the process is terminated directly and FAIL_SAFETY is returned, and a diagnostic summary is recorded in the log.

[0172] 5.47 A more complete example of feature fields, distance metrics, and thresholds (Example 41) In some embodiments, the server side may maintain more complete threshold and feature descriptions to facilitate the interpretation of the judgment criteria.

[0173] 5.47.1 Example of Feature Fields feature_vec / feature_adj can contain the following dimensions (examples): 1) amp_k: The impedance magnitude (or logarithmic magnitude) at frequency fk. 2) phase_k: Impedance phase at frequency fk; 3) peak_pos_j / peak_val_j: spectral peak position and amplitude; 4) band_energy_m: Bandwidth energy; 5) snr_k: Signal-to-noise ratio at key frequency points; 6) noise_var: Noise variance estimate; 7) drift_ind: An indicator of the offset from the historical mean.

[0174] 5.47.2 Threshold Example In some embodiments, the threshold includes, but is not limited to: 1) thr_dist_soft: Soft threshold (passes but marks low confidence); 2) thr_dist_hard: Hard threshold (reject if exceeded); 3) thr_stab: Stability threshold; 4) thr_snr: Minimum signal-to-noise ratio threshold; 5) thr_drift: Drift rating threshold (triggers re-registration).

[0175] The server can dynamically choose to use soft or hard thresholds based on risk strategies. For example, high-risk businesses can use hard thresholds plus multi-challenge consistency.

[0176] 5.48 Example of cause vector and action (Example 42) In some embodiments, the reason code output by the server can be expanded into a reason vector to support more granular processing: 1) rv_session_invalid: The session is invalid or expired; 2) rv_proof_invalid: Invalid signature / authentication code; 3) rv_rulever_mismatch: Inconsistent rule versions; 4) rv_low_quality: Insufficient measurement quality (low SNR / safety protection triggered); 5) rv_distance_high: Distance too high (suspected cloning or vehicle swapping); 6) rv_stability_low: Insufficient stability (noise or environmental changes); 7) rv_drift_suspected: suspected drift.

[0177] The actions to be taken may include: 1) RETRY: Prompts the terminal to retest under the specified operating conditions; 2) REJECT: Deny and suspend gating authorization; 3) RE_ENROLL: Triggers scrolling re-registration; 4) ESCALATE: Raise the risk level and require offline verification.

[0178] 5.49 Closed-loop case study of review and rolling re-registration (Example 43) In some embodiments, when the server detects that the drift_score continues to rise but still meets the soft threshold, a review is initiated: 1) The server issues a set of diagnostic challenges (covering more frequency points or using PRBS); 2) The terminal measures stability multiple times under a specified environmental conditions (e.g., stable idling, heavy load off) and reports the stability statistics. 3) If the review is successful and the stability is high, the server updates the template statistics (e.g., updates the mean / scale) and records the template version; 4) If the verification fails and the distance exceeds the hard threshold, the server will reject the request and trigger RE_ENROLL or ESCALATE.

[0179] In some embodiments, re-registration requires simultaneously satisfying "security component proof of validity + passing multiple challenges + stability requirements" to prevent attackers from using noise or environmental manipulation to complete fake re-registration.

[0180] 5.50 Summary (Example 44) In summary, this invention, through a combination of controlled excitation, synchronous sampling, impedance feature construction, environmental compensation, fuzzy extractor, and security component verification, enables the server to uniquely bind the "physical entity of the vehicle power network connected to the terminal" in an auditable manner, and uses the verification results for gating the generation of key business credentials, thereby achieving a feasible security closed loop in the anti-counterfeiting and risk control scenarios of the Internet of Vehicles.

[0181] 5.51 Numerical Example: Step / Pulse Excitation and Joint Frequency-Time Domain Features (Example 45) In some embodiments, the controlled excitation unit employs step or pulse excitation to shorten the measurement time.

[0182] 1) Step excitation: The terminal connects to a load via a controllable load at time t0 and disconnects the load at time t1, creating a current step. The terminal acquires the voltage response v(t) and extracts: - Rising / falling slope of the step response; - Overshoot amplitude and ringing attenuation constant; - A combination of sampled values ​​at several fixed time delay points.

[0183] 2) Pulse excitation: The terminal outputs a narrow pulse or pulse sequence, acquires the response and calculates the approximate impulse response h(t); performs FFT on h(t) to obtain the equivalent spectrum, and then constructs the joint features of the frequency domain and time domain.

[0184] In some embodiments, to improve distinguishability, frequency domain features (amplitude and phase at several key frequency points) can be concatenated with time domain features (ringing attenuation / peak position), and weights can be assigned to different sub-features in the distance metric. This allows for the simultaneous capture of harness resistance differences (sensitive to low frequencies) and parasitic inductance and capacitance differences (sensitive to high frequencies / ringing).

[0185] 5.52 Multi-environment retesting and robustness determination strategy (Example 46) In some embodiments, to reduce false rejections caused by environmental disturbances, a "multi-environment bucket retesting" strategy can be adopted: 1) When the server fails verification but the risk is not high (e.g., rv_low_quality=1 or rv_stability_low=1), it returns RETRY and prompts the user to retest under the specified conditions. 2) The terminal performs K measurements under different environmental conditions (e.g., different voltage conditions or different load conditions) and reports a summary of stability statistics for each measurement. 3) The server performs robust aggregation on the K results, for example, by using majority voting or taking the median of the distance metric; 4) If the aggregation result meets the threshold, then it is approved and an authorization token is issued; otherwise, a re-registration or upgrade is triggered.

[0186] In some embodiments, the server may adaptively adjust the number of retests based on the terminal's historical performance: 1) Reputable terminals: Allow a small number of retests to reduce false rejections; 2) Higher-risk terminals: Increase the challenge intensity or require multiple challenges to be passed in unison.

[0187] 5.53 Deployment and Operation Recommendations (Example 47) In some embodiments, the following deployment strategies can be adopted to ensure long-term availability and maintainability: 1) The rule_ver publishing channel uses signature configuration and supports grayscale deployment; 2) The template library and thresholds are grouped and maintained according to terminal model / vehicle type, and the threshold distribution is periodically reviewed; 3) Trigger low-risk re-registration in advance for terminals with continuously rising drift scores to avoid sudden failures during critical business operations; 4) Conduct hardware-side troubleshooting for hardware safety protection failures such as FAIL_SAFETY to prevent the measurement link from adversely affecting the vehicle's power supply.

[0188] In some embodiments, the server may output statistical reports (containing only summary-level information) clustered by region / model / version to locate stability degradation caused by a certain batch of hardware or a certain version of algorithm.

[0189] 5.54 Further Explanation It should be understood that the excitation form, frequency set, compensation model, error correction code type, and threshold determination strategy described in this specification can all be replaced and combined under the rule_ver versioning mechanism. The core of this invention lies in: transforming the physical response of the vehicle power network into repeatable measurable features, and using a fuzzy extractor and security components to prove a verifiable commitment, which is then determined by the server threshold and outputs gating authorization, thereby achieving physically unclonable binding and business closed loop.

[0190] 5.55 Enrollment Calibration Process and Parameter Standardization (Example 48) In some embodiments, a registration calibration process is used to establish templates and thresholds during initial binding or re-registration: 1) The server issues a registration challenge set C_enroll={c1..cM}, covering various incentives such as low-frequency / high-frequency, frequency sweep and PRBS; 2) The terminal measures each challenge R times under specified operating conditions to obtain feature_vec_{i,j}, and calculates stability statistics (mean, variance, and test-retest consistency). 3) The terminal outputs helper_data_i and puf_commitment_i for each challenge, and the security component generates puf_proof_i; 4) After the server verifies puf_proof_i, it generates template entries: - template_id, rule_ver, challenge_ref; - Expected feature distribution (e.g., mean vector and scale parameter); - Threshold parameters (soft threshold T_soft and hard threshold T_hard); - The set of allowed environment buckets, env_allow.

[0191] In some embodiments, template entries are grouped by terminal model and vehicle type to avoid mixing statistical distributions of different hardware platforms.

[0192] 5.56 Security Attributes of Fuzzy Extractor and Helper Data (Example 49) In some embodiments, the fuzzy extractor includes two parts: error correction coding and hash extraction. 1) Error correction coding: Map the feature vector to a bit string w, select an error correction code (ECC, such as BCH / RS / LDPC, etc.), and calculate the syndrome or check information as helper_data; 2) Hash extraction: Perform hashing or KDF on the error-corrected result w' to obtain a stable output puf_key or puf_id.

[0193] In some embodiments, helper_data can be stored publicly as error correction assistance information, but it must be bound to a challenge and a session: 1) puf_commitment contains H(helper_data) and challenge_ref to prevent attackers from replacing auxiliary data; 2) The server records the version number and length range of helper_data. If it deviates from the expected range, it outputs rv_helper_mismatch. 3) The security component proof covers puf_commitment, thus enabling helper_data to be authenticated together with the session and rule version.

[0194] In some embodiments, to further reduce the risk of information leakage, helper_data can be minimized: only the necessary number of syndrome bits can be retained, or it can be combined with the salt sent by the server before outputting the digest.

[0195] 5.57 Supplement to Challenge Pool (CRP) Governance and Anti-Replay Strategy (Example 50) In some embodiments, the server maintains a challenge pool and scheduling strategy to reduce the risk of attackers training simulation models by collecting a large number of challenge-response pairs (CRPs) offline. 1) The challenge pool is partitioned by rule_ver and terminal, limiting the number of challenges a single terminal can obtain per unit of time; 2) The challenge includes session_id, nonce, and time-to-live (TTL) validity period; it expires upon timeout. 3) The server outputs rv_replay_suspected and triggers ESCALATE for repeated nonces, repeated challenge_refs, or abnormally high frequency requests; 4) For high-risk businesses (such as signing contracts and making loans), adopt a multi-challenge consistent pass strategy: the threshold needs to be passed under different incentive types.

[0196] In some embodiments, the terminal writes the completed challenge_ref to the local idempotent cache (with an expiration time). If a duplicate challenge is received, it returns an OK_DUP receipt and reuses the existing puf_commitment to avoid repeated stimuli affecting the vehicle's power supply.

[0197] 5.58 Binding strategy for manufacturing, repair and replacement scenarios (Example 51) In some embodiments, considering the operability of manufacturing and maintenance scenarios, the server may support multi-stage binding: 1) Factory delivery stage: Only a basic file (security component certificate, firmware version) for "terminal self-certification validity" is established, and vehicle binding is not immediately fixed; 2) Vehicle installation stage: After the vehicle's power network connection is completed, registration calibration is performed and the vehicle_binding_id is fixed; 3) Maintenance phase: If replacing the wiring harness / battery causes a significant change in impedance characteristics, the server triggers RE_ENROLL and sets the old template to the decommissioned state, while recording the maintenance order number or manual confirmation information; 4) Terminal replacement: Separate the record of changes in the identity of the terminal-side security components from the changes in PUF binding to avoid relying solely on the inheritance of binding relationships during software migration.

[0198] In some embodiments, the server generates auditable logs for the above stages, including time, operator / authorized entity, template version, and cause vector, thereby meeting the requirements for compliance retention and dispute tracing.

[0199] 5.59 Supplement to Privacy Compliance and Data Minimization (Example 52) In some embodiments, the data reported by the terminal to the server follows a minimization principle: 1) Routine reports only include puf_commitment, puf_proof, environment bin number env_bin, and a small amount of quality statistics summary, and do not include the original waveform; 2) Only in review / dispute scenarios, and under the premise of authorization and log recording, a limited number of sampled waveform fragments or feature subsets are retransmitted; 3) Only provide status and reason codes such as "pass / reject / requires review" to external systems, without disclosing internal feature details.

[0200] The above methods can be used to complete uniqueness verification without exposing sensitive physical characteristics, while also taking into account maintainability and compliance requirements.

[0201] 5.60 Supplement to Authorization Tokens and Gating Interfaces (Example 53) In some embodiments, after the server verifies the request, it issues an authorization token (auth_token) to the terminal, which allows the security component to perform critical operations (signing / decryption) within a certain time window. The auth_token may contain: 1) binding_id: Binding identifier; 2) rule_ver: Rule version; 3) grant_scope: the scope of authorization (e.g., "only allow the issuance of certain types of business credentials / only allow the establishment of session keys"); 4) TTL: Expiry date; 5) token_nonce: a random number; 6) token_sig: Server signature.

[0202] When a terminal needs to perform a gating operation, it submits the auth_token along with the business context digest to the security component. The security component verifies the token_sig, checks the TTL and grant_scope before allowing the controlled operation to be executed, and includes the token_nonce in the output for server-side auditing and reconciliation.

[0203] 5.61 Supplement to Server Interface Fields and Idempotency Receipts (Example 54) In some embodiments, terminal reporting and server distribution may use the following set of fields (example, not a limitation): 1) Terminal → Server PUF_REPORT: device_id, session_id, challenge_ref, rule_ver, env_bin, quality_stat, puf_commitment, puf_proof, ts_client; 2) Server → Terminal PUF_ACK: ack_code (OK / OK_DUP / RETRY / REJECT / RE_ENROLL), reason_vector, server_ts, (optional) auth_token.

[0204] In some embodiments, the server uses challenge_ref as the idempotent key: if the same challenge_ref is received repeatedly in PUF_REPORT, OK_DUP is returned and the existing decision result is reused to avoid repeated stimulus and calculation.

[0205] 5.62 Performance, Vehicle Power Supply Impact, and Supplementary Safety Boundaries (Example 55) In some embodiments, to avoid adverse effects on vehicle power supply, the controlled excitation satisfies safety boundaries: 1) Due to limitations in excitation amplitude / duration, short-duration, low-energy frequency sweeps or PRBS should be preferred; 2) Immediately stop excitation and return to FAIL_SAFETY upon detecting a rapid voltage drop or abnormal current; 3) Incentives should be scheduled during the vehicle's stable start-up or idling phase, and should be avoided during critical control phases.

[0206] In some embodiments, the measurement duration can be controlled at the second level, and the MCU load can be reduced through downsampling, pre-calculation and batch processing; the server-side verification mainly involves signature verification and distance measurement calculation, which can support high concurrency through batch scheduling.

[0207] 5.63 Numerical Example of Threshold Calibration (Example 56) In some embodiments, the server statistically analyzes R measurement results collected by a terminal during the registration phase to obtain an empirical distribution of the distance metric (such as weighted L2 distance or cosine distance). For example: 1) The mean of the remeasured distance distribution for the same vehicle is mu_in, and the variance is sigma_in; 2) The mean of the heterogeneous distance distribution obtained for different vehicle or simulator samples is mu_out, and the variance is sigma_out; 3) Choose a soft threshold T_soft to make the same source pass rate high (e.g., allow a small number of retests), and choose a hard threshold T_hard to make the different source false pass rate low.

[0208] In some embodiments, the threshold can also be combined with a stability metric: when the stability_score is below the lower limit, RETRY is triggered even if the distance falls within T_soft, in order to avoid false pass judgments when there is a lot of noise.

[0209] 5.64 Supplementing Audit Logs and Reconciliation Fields (Example 57) In some embodiments, the reconciliation log entries stored by the server and the auditing system may include: device_id, binding_id, rule_ver, challenge_ref, env_bin, quality_stat, distance_metric, stability_score, ack_code, reason_vector, token_nonce, and server_ts. This log is used for: 1) Supports retrospective investigation into "why it was approved / why it was rejected"; 2) Support compliance retention and risk review; 3) Support the periodic recalibration of threshold and parameter set.

[0210] In some embodiments, the log only saves summary-level information and does not save the original waveform; if it is necessary to save sampled waveform segments, the authorizing entity and purpose must be recorded and the retention period must be controlled.

[0211] 5.65 Alternative Implementations and Summary (Example 58) In some embodiments, the distance metric is not limited to weighted L2 distance, but may also use Mahalanobis distance, cosine distance, or confidence scores based on classifiers; the environmental compensation model is not limited to bucket lookup tables, but may also use linear regression, piecewise linear models, or lightweight neural networks, but should be subject to rule_ver versioning control and be auditable and traceable.

[0212] In some embodiments, the controlled excitation unit can either use a controllable load switch to form a step / pulse, or use a small-amplitude AC injection and extract the amplitude and phase through synchronous detection; the sampling link can either use an independent ADC or reuse an automotive-grade sampling chip, but sampling synchronization and clock stability should be ensured.

[0213] In summary, this invention, through a combination of "challenge-driven controlled incentives, synchronous sampling, feature construction, stabilization extraction, security component verification, server threshold determination, and gating authorization," enables the physical differences in vehicle power networks to be engineered into verifiable binding credentials, thereby significantly increasing the cost of spoofing and cloning attacks.

[0214] 5.66 Offline Authorization and Revocation Supplement (Example 59) In some embodiments, considering weak network or offline scenarios, the server can issue a set of short-term offline authorization tokens (with serial numbers and expiration dates). During the offline period, the terminal uses the unexpired and unused tokens to request gating operations from the security component. After the terminal regains network access, it reports the serial numbers of the consumed tokens for server reconciliation. If a risk event is detected, the server can revoke unused tokens through blacklisting or version upgrades, thereby achieving a balance between availability and risk control.

[0215] In some embodiments, the server may also set upper limits on the frequency and total amount of offline tokens issued, and include token consumption in the audit log so as to quickly locate and freeze tokens in case of abnormal consumption or suspected theft.

[0216] In some embodiments, the freeze action may require a retest of the multi-challenge test before authorization is restored.

[0217] It can also issue alarms, etc.

Claims

1. A method for uniquely binding PUF fingerprints based on power network impedance response, characterized in that, The method is executed collaboratively by an in-vehicle terminal and a server. The in-vehicle terminal includes a controlled excitation unit, a voltage sampling circuit and / or a current sampling circuit, a processor and a memory, and a security component for providing a protected key. The security component includes a secure unit or a trusted execution environment. The method includes: the server executing: issuing a challenge parameter, which includes at least one or more of an excitation sequence identifier, a frequency point set, or a timing parameter, and binding a session identifier or a random number; the in-vehicle terminal executing: driving the controlled excitation unit to apply an excitation sequence to the vehicle power network according to the challenge parameter, and acquiring voltage and / or current responses within a sampling window to obtain a response signal; the in-vehicle terminal executing: extracting impedance response features or a fingerprint feature vector (feature_vec) based on the response signal, where the fingerprint features include at least one or more of frequency domain amplitude and phase features, a spectral peak set, energy bandwidth, or time domain impulse response statistics; and the in-vehicle terminal executing: performing environmental compensation, aging compensation, and stabilization processing on the fingerprint features, and generating a PUF output (puf_key) through a fuzzy extractor (fuzzy_extractor). The system generates a PUF fingerprint identifier `puf_id` and / or auxiliary data `helper_data`. The vehicle terminal then performs the following actions: constructing a fingerprint commitment value `puf_commitment`, which is bound to at least the challenge parameter reference information, rule version identifier `rule_ver`, field serialization rule identifier `spec_ver` and / or policy version identifier `policy_ver`, window identifier, a summary of the auxiliary data, monotonic counter reference information `counter_ref`, and compensation version identifier `comp_ver`. The vehicle terminal then triggers the security component to perform an integrity protection operation on the fingerprint commitment value to generate a PUF proof `puf_proof`, and reports the `puf_proof`, the fingerprint commitment value, and the challenge parameter reference information to the server. The server then performs the following actions: processing the `puf_proof`... The system performs signature verification or validation, and executes a threshold determination based on the consistency between the challenge parameters and the fingerprint commitment value. When the threshold determination passes, the in-vehicle terminal is bound to the vehicle physical entity and the generation of key business credentials is allowed. Specifically, when a dispute is triggered, the server issues an audit request carrying an authorization token (auth_token), a field mask (field_mask), a challenge random number (challenge_nonce), and a proof type identifier (proof_type). The in-vehicle terminal outputs a controlled disclosure field set according to the field mask and generates a proof that is bound to the challenge random number and corresponds to the proof type identifier. The server performs a consistency review on the fingerprint commitment value and the controlled disclosure field set to output an audit conclusion.

2. A PUF fingerprint uniqueness binding system based on power network impedance response, characterized in that, The system includes an in-vehicle terminal and a server; wherein the in-vehicle terminal includes a controlled excitation unit, a voltage sampling circuit and / or a current sampling circuit, a processor, a memory, and a security component; the server includes a challenge issuance module, a verification module, and a binding management module; the system is configured to collaboratively execute the method of claim 1.

3. A computer-readable storage medium having a computer program stored thereon, the program being executed by a processor to implement the method of claim 1.

4. The method according to claim 1, wherein the excitation sequence includes one or more of a multi-frequency sweep sequence, a pseudo-random binary sequence (PRBS), a step excitation, or a pulse excitation.

5. The method of claim 1, wherein the impedance response characteristics are obtained by performing a Fast Fourier Transform (FFT), power spectral density estimation, or impedance estimation on the response signal, and the fingerprint characteristics further include a combination of frequency amplitude, phase, or harmonic structure.

6. The method according to claim 1, wherein the environmental compensation includes at least bucket-based correction of temperature, supply voltage, battery state of charge (SOC), or load state, and the rule version identifier rule_ver references the compensation parameter set and the threshold parameter set; wherein the aging compensation includes at least selecting the aging bucket based on the monotonic counter reference information counter_ref and referencing the corresponding aging compensation parameter set.

7. The method according to claim 1, wherein the fuzz extractor includes an error correction coding and hash extraction process, the helper data is error correction code verification information or syndrome information, and the helper data does not disclose the valid information of the puf_key.

8. The method according to claim 1, wherein the security component further derives a session key based on the puf_key, and allows integrity protection operations or encryption operations to be performed on the service load only when the server verification is successful, so as to implement a "PUF pass - sign / encryption only" gating policy; and the excitation path of the controlled excitation unit is enabled by a hard-wired gating signal, the hard-wired gating signal is transmitted along the gating signal path from the security component to the controlled excitation unit, and is only allowed to be turned on when the physical conduction conditions and optional timeout semantic constraints are met, so as to avoid the service side bypassing the controlled excitation and sampling aperture.

9. The method according to claim 1, wherein the server employs a challenge-response retry and idempotent deduplication strategy, and constructs an idempotent key EvidenceId based on terminal identifier reference information, challenge parameter reference information, rule version identifier rule_ver, and / or field serialization rule identifier spec_ver to deduplicate duplicate reports; the server receipt includes at least OK or OK_DUP, and returns REJECT upon verification failure, optionally carrying a rejection reason code RejectReason, and optionally returns RETRY with a suggested retry time next_retry_after.

10. The method according to claim 1, wherein the threshold determination is based at least on one or more of the distance metric, stability score, or freshness of the fingerprint feature vector, and a rolling re-registration or threshold adaptive update strategy is adopted for fingerprint drift; wherein when the compensation parameter or threshold parameter is updated, the server issues a signed parameter package and binds the applicable counter_ref range with the compensation version identifier comp_ver to suppress parameter rollback.

Images