Vehicle-mounted terminal trusted data generation and signature gating method and device and storage medium

Abstract

The invention discloses a vehicle-mounted data credible generation method and device and a storage medium. And the vehicle-mounted terminal collects power supply voltage in the time window and generates physical side characteristics, collects vehicle bus data to generate logic side characteristics and performs time alignment, and calculates consistency measurement to obtain a judgment result. Generating an abstract from the data block to be reported according to the normalized code, and binding the abstract with the window identifier, the monotonic counter reference information and the measurement rule version identifier; when it is judged that a preset condition is met, a security component (security unit / trusted execution environment) executes a signature or an authentication code on the abstract to generate a state verification voucher; and if not, outputting a failure reason code and optionally generating an abnormal audit voucher capable of being verified. In some embodiments, a lightweight digital twinning model or predictive model is executed within a security component, physical / logical side observability measurements at the next moment are predicted based on load-related characteristics, and gating is performed on predicted residuals to identify smart simulator attacks. According to the scheme, playback, injection and middle box playback are inhibited, and the authenticity and proof performance of the afterloading OBD scene data are improved.

Description

Technical Field

[0001] This invention belongs to the field of vehicle network data collection and security evidence collection, and in particular relates to a method, device and storage medium for trusted generation and signature gating of vehicle data for aftermarket OBD scenarios. Background Technology

[0002] When aftermarket OBD devices are used for scenarios such as risk control based on usage behavior, vehicle health analysis, and accident dispute review, they typically rely on vehicle diagnostic interface or on-board bus (OBD / CAN) messages as the primary data source. Because aftermarket terminals are vehicle peripherals, their physical access paths, power supply paths, and data paths are easily manipulated. In the absence of verifiable end-side trusted mechanisms, the cloud often struggles to determine whether the data originates from a real vehicle, has undergone tampering in intermediate stages, or is a replay based solely on the "reasonableness of the data content." This makes it difficult to prove the authenticity of the data, leading to disputes, failure of risk control models, and compliance risks.

[0003] More specifically, common sources of interference and distortion in aftermarket OBD scenarios include at least the following: 1) Simulator / Dock Replay: Attackers construct or replay historical packets in an offline environment, making it difficult for the server to determine from the field values ​​that they come from real vehicle operation; 2) Intermediate box insertion: Insert a hardware relay or gateway between the OBD port and the terminal to forward and selectively tamper with messages, forming a "seemingly legitimate" data flow; 3) Bus injection and replay: Injecting fake messages into the CAN bus or replaying buffered messages, causing logical fields such as vehicle speed, RPM, and mileage increment to be forged; 4) Plug-in escape and power failure interference: By short-term plug-in, power failure disturbance or induced reset, the data collection and reporting process is bypassed, or an unverifiable gap is created. 5) Reproducibility of pure software signatures: If the signature is completed in the software environment of a regular MCU, there is a risk that the key may be extracted or cloned to multiple devices, making "verifiable signature" not equivalent to "trusted source".

[0004] Existing technologies also include signing or encrypting data for upload. However, if the signature triggering condition only depends on logical-side fields (such as vehicle speed and RPM), it is vulnerable to "logical-side forgery" attacks. If the signature trigger does not include a verifiable rejection / abnormal path, the server lacks structured evidence to determine the cause and risk level of the abnormality once an anomaly occurs. If the signature material is not bound to a time window and a monotonic counter, replaying the data may obtain a valid signature again at different times, thereby disrupting the temporal consistency of the evidence chain.

[0005] Therefore, a closed-loop evidence mechanism that can be "verifiable and retrievable" at the terminal side and during the data generation stage is needed: gating signatures are performed on key data blocks; a structured failure reason code is given and an abnormal audit record is generated for cases where gating fails; and, in optional cases, a verifiable abnormal audit credential is generated from the summary of the abnormal audit record, so that the server can distinguish between "trustworthy data that has passed the gating" and "data that has been rejected / marked as abnormal" and has a retrievable tool in dispute scenarios. Summary of the Invention

[0006] (a) Purpose of the invention This paper presents a reliable vehicle data generation solution that can be implemented in engineering, enabling key data to be bound to verifiable credentials during the generation stage, and triggering rejection or anomaly marking for situations such as forged input, intermediate box tampering, and replay. At the same time, it enhances maintainability and evidentiary value through structured audit information.

[0007] (II) Technical Solution This invention provides a method for generating trusted vehicle data, executed by an on-board terminal comprising a voltage sampling circuit, a vehicle bus interface, and a security component for providing a protected key. The security component may be a security element, SE, TPM, TEE, or an equivalent implementation. Figure 2 As shown (illustrative), it includes: 1) Obtain the power supply voltage sequence and generate at least one physical side feature; 2) Obtain at least one logical feature related to the vehicle's operating status; 3) Perform time alignment on the physical side features and the logical side features within a preset time window, and calculate a consistency metric to obtain a consistency decision result; 4) Perform field normalization encoding on the data blocks to be reported, and generate a data block summary based on the normalization encoding result. The data block summary is bound to at least the window identifier of the time window, the monotonic counter reference information, and the summary standard version identifier. 5) When the consistency decision result meets the preset conditions, the security component is triggered to perform an integrity protection operation on the data block digest to generate a status verification credential. The integrity protection operation includes a digital signature or a message authentication code, and the status verification credential is associated with the data block to be reported and output. 6) When the consistency decision result does not meet the preset conditions, refuse to sign the data block digest and generate an abnormal audit record.

[0008] To facilitate alignment between review and engineering implementation, this invention forms the following "end-side evidence closed loop" (not constituting a limitation): gating signatures are performed on data block summaries in units of time windows; if gating passes, a status verification credential is output; if gating fails, the signature is rejected and a structured anomaly audit record is output, and optionally, anomaly audit credentials are generated by signing the anomaly audit record summary; the credential is bound to the window identifier, monotonic counter reference information, and (optionally) challenge random number reference information; the terminal uses EvidenceId as the idempotent key to offline archive and reissue; the server deduplicates according to EvidenceId and returns an AckCode (OK / OK_DUP / REJECT / RETRY) to close the end-cloud consistency caliber.

[0009] In an optional embodiment, the technical solution further includes: 7) Receive challenge random numbers sent by a remote server and bind the challenge random numbers to data block digests to combat replay and middlebox replication; 8) Anomaly audit logs should include at least the consistency metric, the version identifier of the preset conditions, and the failure reason code; 9) The vehicle terminal triggers the security component to perform integrity protection operations (including digital signatures or message authentication codes) on the summary of the abnormal audit record to generate an abnormal audit credential and bind it with the corresponding window identifier / counter reference information.

[0010] In one optional embodiment, the vehicle terminal triggers the security component to perform an integrity protection operation on the summary of the abnormal audit record to generate an abnormal audit credential; the abnormal audit credential is used to provide verifiable proof of the generation process of the abnormal audit record.

[0011] In one optional embodiment, when communication is unavailable, the terminal will offline archive the status verification credential or the anomaly audit credential and resend it in the order of the counter when communication is restored; the server will perform idempotent processing on the duplicate resends by pressing the deduplication key and return an idempotent receipt.

[0012] In one alternative embodiment, the monotonic counter is stored in or bound to a rollback prevention area, making it difficult for repeated windows or replay data blocks to generate new status verification credentials.

[0013] (III) Beneficial Effects Compared with the prior art, the present invention has at least the following technical effects: 1) Push the trustworthy constraints from the cloud-based post-hoc stage to the edge-side generation stage to form verifiable signature evidence; 2) Introduce cross-constraints between the physical and logical sides to improve the detection and rejection capabilities for replay, injection, and intermediate box tampering; 3) By performing gated signatures through a secure unit, the risk of "forged and verifiable signatures" caused by key export and device cloning is reduced; 4) Output structured failure reason codes through the rejection path, and optionally generate exception audit credentials, enabling the server to handle exceptions in a tiered manner and support dispute review.

[0014] 5) By binding the random number / counter reference information and the EvidenceId idempotent receipt closed loop, the edge and cloud have a consistent standard for receiving, deduplicating, verifying signatures and recalculating vouchers in the same window, reducing the risks of replay, duplicate counting and misjudgment. Attached Figure Description

[0015] To facilitate the explanation of the technical solution of the present invention, the accompanying drawings are used for illustrative purposes. Those skilled in the art can make equivalent substitutions to the drawings without departing from the spirit of the present invention.

[0016] Figure 1 A schematic diagram of the overall structure of the vehicle data trust generation system; Figure 2 A schematic diagram of the method for trusted generation and signature gating of vehicle data; Figure 3 This is a schematic diagram of the field structure of the data block and the status verification credential; Figure 4 A diagram illustrating the closed-loop evidence process for refusal to sign and abnormal audits; Figure 5 A schematic diagram illustrating the interaction sequence of server challenge random number binding and signature verification. Detailed Implementation

[0017] The embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. It should be understood that the embodiments described are for illustrative purposes only and are not intended to limit the scope of the invention.

[0018] 5.0 Terms and Definitions For ease of understanding, the following terms are used to describe the implementation of the present invention: In addition, the specific values ​​of "preset conditions / thresholds / rules / calibers" mentioned herein are preferably determined by the corresponding version identifier (e.g., spec_ver or rule_ver) and bound together with the voucher to support review and traceability; differences in field name capitalization or window_id / window_ref, counter_ref / CounterRef / CtrRef / ctr_ref, policy_ver / PolicyVer, spec_ver / SpecVer, rule_ver / RuleVer, nonce / Nonce, nonce_ref / NonceRef, ack_code / AckCode, etc. are only synonymous examples and do not constitute a limitation.

[0019] 1) Physical side characteristics: Characteristic quantities extracted from power supply voltage timing, ripple, or undervoltage dynamics, etc. 2) Logical side characteristics: Characteristic quantities reflecting the operating status, such as vehicle speed, RPM, and mileage increment, obtained from the vehicle bus; In some embodiments, the logical side features include at least one of vehicle speed, engine speed, and mileage increment.

[0020] 3) Consistency metric: A metric used to measure the consistency between physical and logical features within a time window. It can be a correlation, mutual information, time series similarity, or constraint consistency metric. 4) Preset condition version identifier: Used to indicate the threshold / parameter version used for consistency judgment, which facilitates review and traceability; 5) Status verification credential: A verifiable credential generated by the security element signature, used to prove that the data block digest was gated and signed during the edge generation stage; 6) Monotonic counter reference information: The counter value or its reference information used for anti-rollback / anti-replay, which can be maintained by the security cell or bound to the anti-rollback zone; 7) Failure Reason Code: A structured reason code used to identify rejection, judgment failure, verification failure, or abnormality in a critical step; in some embodiments, this reason code is an end-side / local reason code (which can be written into the audit log), which is different from the rejection reason code RejectReason that can be carried in the server receipt.

[0021] 8) Idempotent key EvidenceId: Used to identify and reissue idempotent status verification credentials or abnormal audit credentials; in some embodiments, EvidenceId is obtained by calculating the digest after deterministic encoding of terminal identifier reference, window identifier reference, counter reference information, challenge random number reference (if enabled), and digest specification version identifier, thereby binding the deduplication key to the caliber version / window / counter (and random challenge).

[0022] 9) Idempotent Acknowledgment Code (AckCode): The server's acknowledgment code after deduplicating EvidenceId; the acknowledgment code includes at least OK (first reception) and OK_DUP (repeated reception), and optionally includes REJECT (signature verification failed, format mismatch or missing key fields, etc.; optionally carries rejection reason code RejectReason) and / or RETRY (server cannot process temporarily or triggers rate limiting, suggests retrying; optionally carries suggested retry time or backoff parameters).

[0023] 10) Suggested retry time next_retry_after: The suggested next retry time field can be carried by the server receipt when ack_code=RETRY, and is used for terminal backoff retries and peak shaving.

[0024] 11) Usage Restriction / Usage Tag: The security component performs differentiated authorization control on signature requests for different purposes; in some embodiments, the generation of status verification credentials for business purposes is prohibited in the state of key revocation or risk disposal, while the generation of anomalous audit credentials for audit purposes is allowed, so as to preserve the ability to provide evidence.

[0025] For the dictionary attributes of fields related to EvidenceId / AckCode (data type, unit scaling, missing semantics, Bind, etc.) and the standardized encoding, please refer to 6.1.2 and 6.13.

[0026] 5.0.1 Key Field Dictionary (Example, not a limitation) In some embodiments, the server may issue an audit request in a review scenario triggered by a dispute; after verifying the auth_token of the audit request, the terminal selectively generates or extracts review materials based on policy_level and field_mask, and reports them in association with challenge_nonce and EvidenceId, so as to complete the consistency review without exposing unnecessary information.

[0027] 5.0.2 Index of Optional Embodiments (Non-limiting) For ease of understanding, the locations of embodiments related to several optional features in this specification are exemplified as follows (not constituting a limitation): challenge random number binding (see item 7 of the technical solution of the invention) and Figure 5 ); Exception audit record fields and failure reason codes (see 6.13.3 and Figure 4 The integrity protection operation of the abnormal audit record summary generates abnormal audit vouchers (see 5.9 and...). Figure 4 Monotonic counter / anti-rollback binding and anti-replay (see 5.2, 5.10 and related embodiments); offline archive resending and idempotent receipt (see related receipt fields and resending process embodiments).

[0028] In this specification, "digest" can refer to a hash digest, a message authentication code digest, or a combination thereof; "digital signature" can refer to a signature algorithm based on an asymmetric key (such as ECDSA, SM2, etc.) or an equivalent algorithm. This invention does not limit specific algorithms, but the same credential may include an algorithm identifier and a version identifier for verification purposes.

[0029] 5.1 System Structure (see...) Figure 1 ) like Figure 1 As shown, the vehicle-mounted terminal may include: 1) Voltage sampling circuit, used to acquire the vehicle power supply voltage sequence; 2) Vehicle bus interface, used to acquire logical side features such as vehicle speed, RPM, or mileage increment; 3) A secure unit for storing keys and performing digital signatures; 4) Processor and memory for feature extraction, consistency determination, digest construction, and audit logs; 5) Communication module, used to report data blocks and status verification credentials, and optionally report abnormal audit credentials.

[0030] In one embodiment, the security unit may be a standalone security chip (SE), a trusted platform module (TPM), a security isolation execution environment integrated into the main controller, or a hardware security module (HSM) with non-exportable key characteristics, etc., which are characterized in that the signing private key or signing key is stored in a non-exportable manner, and the signing operation is completed within the security boundary.

[0031] In some embodiments, the security unit may be integrated with the processor on the same chip (SoC) and implemented as an on-chip security island, isolated execution environment, or equivalent hardware isolation domain. The SoC may include on-chip access control logic or an isolation bus for restricting service-side access to the key storage area, monotonic counter / anti-rollback area, and signature engine registers. Keys can be written or derived via eFuse / OTP or equivalent immutable media and are invoked only within the security boundary in a non-derivative manner.

[0032] In some embodiments, to ensure the consistency between gating decisions and signature inputs, the SoC can use a hardware state machine or a controlled scheduling mechanism to constrain the execution order of key steps in the process of "digest normalization - gating check - constructing input to be signed - triggering signature", and write failure reason codes (field name example: failure_reason) and key step status codes (field name example: step_code) in abnormal paths; the version identifier of the hardware state machine / scheduling mechanism can be associated with policy_ver / spec_ver (and optional rule_ver) and written into audit records or credentials so that the server side can verify the implementation standards.

[0033] In one embodiment, the vehicle terminal further includes a local clock module for timestamping the sampling sequence; the local clock module can work with the communication module to correct clock drift through network time synchronization or by sending time calibration information from the server.

[0034] 5.2 Preset Time Window and Window Identifier To organize continuously sampled data into signed and verifiable data blocks, this invention introduces a preset time window. Let the window length be $T_w$ and the window step size be $T_s$, then the $k$-th window $W_k$ can be represented as $[t_0+k\cdotT_s,\ t_0+k\cdot T_s+T_w)$.

[0035] A window identifier is used to uniquely identify a window, and a window identifier can be generated in the following unrestricted ways: 1) Encoded by combining window number $k$ with terminal identifier and time base; 2) Encoded by combining the window start and end timestamps with the terminal identifier; 3) Calculate the digest from the “window start and end timestamps + terminal identifier + version identifier”.

[0036] In one embodiment, the window identifier may also include window parameter versions (e.g., $T_w$, $T_s$, sampling rate, etc.) to enable the server to determine the consistency of the window definition during review.

[0037] 5.3 Physical side data acquisition and feature extraction Physical features may include, but are not limited to: ripple amplitude, peak frequency, harmonic structure, energy bandwidth, undervoltage duration, and number of abrupt changes. Feature extraction can be achieved using frequency domain or time domain methods.

[0038] In one embodiment, the voltage sampling circuit acquires the supply voltage sequence $V(t)$ at a preset sampling rate and forms a discrete sequence $\{V_k(i)\}$ in units of windows $W_k$. The following features can be extracted for each window (example): 1) Mean and variance: $\mu_k=\mathrm{mean}(V\mid W_k)$, $\sigma_k=\mathrm{std}(V\mid W_k)$; 2) Peak-to-peak value of ripple: $A_k=\max(V\mid W_k)-\min(V\mid W_k)$; 3) Frequency domain main peak and harmonics: Perform discrete Fourier transform on $V(t)$ to obtain the spectrum $S(f)$, and extract the amplitude / frequency position of the main frequency peak and several harmonic peaks; 4) Undervoltage and mutation: For example, count the cumulative duration $D_k$ when $V(t)$ is below the threshold $V_{low}$, and the number of mutations $C_k$ that exceed the slope threshold.

[0039] In one embodiment, the physical side features may also carry a "feature extraction algorithm identifier / version identifier" to distinguish the meaning of features under different hardware versions and different sampling rate conditions.

[0040] 5.3.1 CAN Ringing / Echo Physical Characteristics (Optional) In some embodiments, in addition to vehicle power supply voltage ripple / undervoltage dynamics, the terminal may also utilize the transient response of the vehicle bus physical layer as one of the physical-side characteristics to enhance the detection capability of "pure message replay / emulator replication / intermediate box forwarding". For example: 1) Under the premise of meeting safety conditions (e.g., bus is idle, will not affect normal communication, and meets the upper limit of amplitude / duration), the terminal generates a short-term standardized excitation through controlled mode switching of the CAN transceiver, connection / disconnection of the controllable terminal resistor or equivalent controlled load; 2) The terminal collects the ringing attenuation curve of the bus voltage or the sampled values ​​of several characteristic delay points, and forms the bus_ring_feature according to the quantization / bucketing caliber referenced by the rule_ver (or equivalent version identifier); 3) Bind the bus_ring_feature with the window identifier, counter reference information and (optionally) server challenge random number reference information and write it to the summary or anomaly audit log so that the server can use it as a physical consistency input or risk-weighted input when reviewing.

[0041] By introducing transient responses at the bus physical layer, evidence sources that are "hard to simulate on the physical side" can be added without relying on additional peripheral sensors, and cross-constraints can be formed with logical-side fields.

[0042] 5.4 Logical Side Data Acquisition and Feature Construction Logical side features may include, but are not limited to: vehicle speed, engine speed, mileage increment, etc. Logical side features may come from OBDPID, CAN messages, or equivalent fields.

[0043] In one embodiment, logical-side features are acquired as a sampling sequence within the same window $W_k$, and source identifiers and availability flags are set for different sources. For example: 1) If vehicle speed and RPM are obtained from OBD PID, then record the PID identifier and response status; 2) If the vehicle speed and RPM are obtained from parsing the original CAN message, record the message ID and parsing configuration version; 3) If auxiliary sensors (such as IMU, GNSS) are present, the source identifier is recorded and used as an optional input in the consistency decision.

[0044] In one embodiment, when a logical field is missing, jumps abnormally, has an incorrect timestamp, or does not match the window boundary, the exception can be written into the failure reason code and the process can proceed to the rejection or downgrade path.

[0045] 5.5 Time Alignment and Consistency Measurement In order to compare the change trends of the physical side and the logical side within the same window, the present invention performs time alignment on the physical side features and the logical side features within a preset time window and calculates a consistency metric.

[0046] Time alignment can be performed in one of the following non-restrictive ways: 1) Unified time source alignment: Voltage sampling and bus sampling use the same hardware timer or the same system clock; 2) Timestamp interpolation alignment: Interpolate or resample the logic-side sequence at a lower sampling rate to match the voltage sampling window; 3) Event anchor alignment: Using events such as engine start, acceleration, braking or idling stability as anchor points, local alignment is performed on different sequences.

[0047] Consistency measures can be a single measure or a combination of measures. For example, any of the following can be used: correlation measure, mutual information measure, time series similarity measure, or constrained consistency measure.

[0048] As a non-restrictive example, the constraint consistency metric is used to verify whether changes on the logical side and the physical side satisfy preset constraints. For example, when vehicle speed increases, engine load increases, or electrical load changes, the supply voltage ripple, undervoltage events, and harmonic structure may exhibit interpretable changes; if the logical side displays "high speed and high load," while the physical side characteristics remain stable over a long period or deviate significantly from historical vehicle profiles, then inconsistency can be determined.

[0049] In some embodiments, the consistency metric further includes a predictive consistency metric (not limited): a lightweight engine / electrical load digital twin model or predictive model executed within a security component (e.g., TEE) predicts one or more target observables (e.g., quantized values ​​of intake air volume / manifold pressure, rate of change of engine speed, supply voltage ripple statistics) for the next moment or the next sub-window based on load-related logical side features (e.g., engine speed, load, quantized values ​​of throttle opening or their summaries) and the environmental context within a window. The terminal calculates the residual vector or residual scalar $r$ between the predicted value and the actual observed value and compares the residual with a threshold; when the residual exceeds the threshold, it is determined that the prediction consistency has failed and enters the rejection / abnormal audit path to suppress adversarial forgery based on the intelligent simulator.

[0050] In some embodiments, the prediction model employs deterministic reasoning and quantified input and output, and is referenced by version identifiers (e.g., ModelVer, FeatureSetVer, ThresholdVer / PolicyVer). The version identifiers and residual reference information are written into the decision reference field or anomaly audit record to support server-side review and consistent interpretation.

[0051] Furthermore, in some embodiments, to avoid inconsistencies in summary / judgment due to "differences in model implementation," the reasoning process of the prediction model satisfies at least one of the following (not limiting): 1) Fixed-point quantization and determinism: The model input / output adopts fixed-point quantization and deterministic operators (such as table lookup, linear recursion, fixed-point implementation of ARX / Kalman filtering or fixed-point implementation of small regression models) to avoid inconsistencies across devices caused by floating-point differences; 2) Resource upper bound: Model inference is completed within the preset resource upper bound, including at least one of the upper bound of computation latency, upper bound of memory usage, and upper bound of energy consumption, so that the gated signature still satisfies the real-time performance of window processing; 3) Controlled Updates: The ModelVer / FeatureSetVer / threshold parameters are referenced by PolicyVer and can be issued by the server with signature. The terminal verifies the signature or integrity before enabling the update to reduce the risk of attackers reducing the gating strength by tampering with the model parameters. 4) Rollback capability: When the model version is unavailable, inference is abnormal, or sampling quality is insufficient, the terminal can roll back to a gated path that does not enable prediction consistency measurement, and record the corresponding failure reason code or downgrade flag in the anomaly audit log.

[0052] 5.5.1 Algorithm flow for predicting consistency metrics (example) In some embodiments, to enable those skilled in the art to implement predictive consistency metrics, the terminal may execute the following deterministic process (non-limiting) within each window or sub-window: 1) Input Construction: Select load-related fields from the logical side field set and normalize and quantize them in the order specified by FeatureSetVer to obtain the input vector $x_k$; $x_k$ may include at least one of the following: engine speed $rpm_q$, load $load_q$, throttle opening $throttle_q$, coolant temperature $temp_q$, vehicle speed $vspd_q$, and their differential / slip statistics.

[0053] 2) Context Selection (Optional): Select the model parameter group or lookup branch based on the environment context field (e.g., ambient temperature bucket, altitude bucket, power status bucket, etc.), which is referenced by ModelVer / ParamSetVer.

[0054] 3) Deterministic reasoning: Perform fixed-point inference based on model parameters within a safe component or protected execution environment, and output the predicted value of the target observable $\hat{y}_{k+1}$ or $\hat{y}_{k+\Delta}$; the target observable $y$ can be a quantized value of intake volume / manifold pressure, speed change rate, power supply voltage ripple statistics, etc.

[0055] 4) Residual calculation: Perform quantization on the actual observed value $y_{k+1}$ with the same caliber, and calculate the residual $r$, for example, $r=|y_{k+1}-\hat{y}_{k+1}|$, or use the weighted distance $r=\sum_i w_i\cdot|y^{(i)}-\hat{y}^{(i)}|$ for multi-target output.

[0056] 5) Decision and Output: Compare the residual $r$ with the threshold $thr$ or the threshold pair $(thr_{low},thr_{high})$; if $r>thr$ (or exceeds the range), output "Prediction Consistency Failure" and proceed to the rejection / abnormal audit path; otherwise, output "Pass". The terminal can write the quantized value of $r$ or its summary reference, the threshold version identifier, and ModelVer / FeatureSetVer together into the decision reference field for interpretation and verification by the server side.

[0057] 5.5.2 Model Form, Parameters, and Fixed-Point Implementation (Example) In some embodiments, the lightweight digital twin model or prediction model may take at least one of the following forms (not limited) and be represented by a parameter vector $\theta$ or a set of parameter matrices: 1) ARX / Linear Recursive Model: $$\hat{y}_{t}=\sum_{i=1}^{p} a_i\,y_{ti}+\sum_{j=0}^{q} b_j\,u_{tj}+c$$ where $u$ is the input component chosen by $x$ or a linear combination thereof; the parameter set $\theta=\{a_i,b_j,c\}$ and the order $(p,q)$ are referenced by ModelVer / ParamSetVer.

[0058] 2) State-space / Kalman filter model (deterministic fixed-point implementation): $$x_{t+1}=A x_t + B u_t,\quad \hat{y}_t=C x_t + D u_t$$ where $A,B,C,D$ are fixed-point matrices; when filtering is required, the fixed-point Kalman gain $K$ can be recursively updated, and the output is determined under the same input sequence.

[0059] 3) Bucket lookup table and piecewise linear model: Map the input $x$ to the bucket index $idx$, and look up the table to get the parameter or directly look up the table to get $\hat{y}$; or use piecewise linear interpolation between adjacent buckets and specify deterministic rounding.

[0060] To ensure consistency across devices, in some embodiments, the fixed-point implementation adopts a fixed Q format (e.g., Qm.n) and uses deterministic rules for multiply-accumulate, overflow, and rounding (e.g., a fixed implementation of zero truncation or banker's rounding), and performs clamping and missing bucket encoding on inputs and outputs; the Q format and rounding rules can be referenced by ModelVer / CodecVer.

[0061] 5.5.3 Training / calibration data processing and parameter generation methods (example) In some embodiments, model parameters can be obtained through offline training or offline calibration and distributed in the form of parameter packages; to meet feasibility requirements and without necessarily disclosing raw data, the training / calibration process can process data in the following manner (non-limiting): 1) Data source: The collected training / calibration samples can come from bench data, road test data or statistical summary data from historical windows; preferably, only quantitative features and target quantities related to model fitting are output to the external training environment, avoiding the inclusion of fields that can identify individuals or trajectories.

[0062] 2) Time alignment: Align multi-source samples with a unified sampling grid, fill missing points with "missing buckets" or the most recent value, and write the missing flag into the sample flag bit.

[0063] 3) Quantization and Normalization: Map continuous values ​​to discrete bucket numbers or fixed-point integers according to FeatureSetVer / CodecVer, and perform pruning on out-of-bounds values; quantization bucket width, minimum / maximum value and missing codes are all versioned records.

[0064] 4) Anomaly Removal: Remove abnormal samples based on physical reasonable range, mutation threshold, or quality flag; removal rules and thresholds are referenced by ThresholdVer / PolicyVer.

[0065] 5) Training / fitting: For the sample set $\{(x_t,y_t)\}$ after the above processing, solve for the parameter $\theta$ using methods such as least squares, robust regression or recursive least squares; and write the order $(p,q)$, regularization coefficient, stopping condition, etc. as hyperparameters into ParamSetVer (or its abstract reference).

[0066] 6) Validation and threshold determination: Calculate the residual distribution (e.g., the quantiles of $|y-\hat{y}|$) on the independent validation set, and determine the fixed threshold $thr$ or the dynamic threshold parameter $(\alpha,\beta,N)$ accordingly; the threshold determination method, the corresponding parameter group identifier, and the model version are recorded together to support subsequent audit interpretation.

[0067] Using the above processing method, those in the relevant technical field can replicate practical training / calibration processes without relying on specific private dataset details, and generate parameter sets that can be deterministically executed by the terminal.

[0068] 5.5.4 Parameter package release, signature verification activation, and auditable backtracking (example) In some embodiments, the server publishes a signed model / parameter package (model_pack, not limited) to the terminal, which may include at least: ModelVer, FeatureSetVer, CodecVer, ParamSetVer / parameter hash reference, ThresholdVer (threshold version identifier), validity period (valid_from / valid_to), and signature value sig_model_pack. Before enabling the model_pack, the terminal verifies the signature and checks the validity period and rollback constraints; and writes the enabled ModelVer / ParamSetVer / ThresholdVer as binding fields into the window decision reference field or anomaly audit record. During review, the server can use this to locate the corresponding version parameters and threshold caliber, thereby determining whether the prediction consistency failure is due to "model caliber issues, parameter version issues, or abnormal operating conditions."

[0069] 5.5.5 Residual-driven gating and hardware interaction (example) In some embodiments, the residual $r$ of the predicted consistency metric does not exist merely as a mathematical calculation result, but rather participates as a gating control signal in the terminal's hardware interaction and credential generation path selection, exemplified by: 1) After the terminal completes the comparison between $r$ and the threshold $thr$, it generates a gate bit gate_pass (e.g., gate_pass=1 indicates success, gate_pass=0 indicates failure).

[0070] 2) When gate_pass=1, the terminal writes the data block digest or window digest to the sign buffer sign_buf (or submits the digest input to the security component) and triggers the security component to perform integrity protection operations to generate state verification credentials.

[0071] 3) When gate_pass=0, the terminal refuses to write the digest to be signed to sign_buf or refuses to call the security component's signing interface (or the security component refuses to sign when it receives the binding field with gate_pass=0), and enters the exception audit path: generates an exception audit record containing failure reason code and residual reference information, and triggers the security component to perform integrity protection operation on the exception audit digest to generate exception audit credentials.

[0072] In this way, the residual $r$ can directly determine whether to trigger the key use and signing operation of the security component, thereby producing a verifiable technical effect: suppressing the signature endorsement of suspicious data blocks when predictive consistency failure is detected, and outputting verifiable audit evidence of anomalies.

[0073] In some embodiments, to meet the computing power and energy consumption constraints of the vehicle terminal, the deterministic reasoning can be executed on a processor or acceleration unit containing DSP / SIMD / vector instruction sets to accelerate fixed-point multiplication and addition, table lookup and piecewise linear calculations; however, it is preferable to maintain a fixed Q format, fixed rounding / overflow rules and fixed operator sequences to ensure cross-device output consistency.

[0074] In one embodiment, the threshold can be a fixed threshold or a dynamic threshold. A non-limiting example of a dynamic threshold is: adaptively setting the threshold based on the distribution of the most recent $N$ metrics passing through the window $$\theta_k=\alpha\cdot\mathrm{median}(m)+\beta\cdot\mathrm{MAD}(m)$$ where $m$ is the historical metric sequence, and $\alpha,\beta$ are configuration parameters. The terminal can write the threshold version identifier and parameter group identifier into the audit log, which the server uses for interpretation and verification.

[0075] The output of a consistency decision may include at least one of the following: consistency metric, threshold version identifier, decision result, and failure reason code, and shall be written to the audit log.

[0076] 5.6 Data block construction, summary normalization, and field binding (see...) Figure 3 ) like Figure 3As shown, the vehicle-mounted terminal constructs data blocks to be reported in units of time windows. A data block may contain: window identifier, sampling start and end timestamps, terminal identifier, vehicle identifier (or its anonymized representation), logical side field set, physical side feature set, and optional compression / blocking information.

[0077] To ensure consistent summary results for the same set of fields across different implementations, data block summaries can be generated using a combination of "field normalization encoding + summary algorithm". Field normalization encoding can be ordered concatenation, TLV encoding, CBOR encoding, or other structured encodings; and a "summary specification version identifier" can indicate the field order, encoding rules, and summary algorithm identifier.

[0078] In one embodiment, the data block digest is bound to at least a window identifier and a monotonic counter. Specifically, the digest input may include, but is not limited to: 1) Window identifier or its reference information; 2) The value of the monotonic counter or its reference information; 3) A normalized representation of the logical field set or its summary; 4) A normalized representation or summary of the physical feature set; 5) Decision reference fields (e.g., metric summary, threshold version identifier, decision result bits).

[0079] 5.7 Monotonic Counter and Anti-Rollback Mechanism A monotonic counter is used to constrain the consistency of the time direction of voucher generation and reduce the risk of obtaining new vouchers repeatedly at different times during the replay window.

[0080] In one embodiment, the monotonic counter may be maintained internally by the security unit or stored in the rollback protection area of ​​the security unit; in another embodiment, the monotonic counter is stored in the protected area of ​​the terminal and is bound to the rollback protection counter or a trusted measurement value of the security unit.

[0081] For example, the terminal can read the current monotonic counter value $ctr_k$ before generating a voucher in each window, include it in the digest binding field, and atomically update it to $ctr_{k+1}$ after successful signing; if the update fails or rollback or duplication is detected, an abnormal audit record is generated and the corresponding failure reason code is written.

[0082] 5.8 Gated Signature and Status Verification Credentials (see...) Figure 2 , Figure 3 ) like Figure 2As shown, when the consistency decision meets the preset conditions, the terminal triggers the security unit to perform a digital signature on the data block digest to generate a state verification credential; when the preset conditions are not met, the signature is rejected and an abnormal audit record is generated.

[0083] A status verification credential may include: a signature value, a timestamp, a window identifier reference, a monotonic counter reference, and a decision reference. The server can use the corresponding public key to verify the signature and associate the credential with the data block for storage.

[0084] To reduce bandwidth and computational overhead, credentials can cover only the digest and key reference fields; at the same time, the terminal can associate the "public key identifier, certificate chain identifier or key version identifier used for signature verification" with the credential so that the server can select the correct verification material.

[0085] 5.9 Closing the loop between refusal to sign, unusual audits, and adversarial evidence (see...) Figure 4 ) like Figure 4 As shown, when the consistency decision does not meet the preset conditions, the security unit refuses to sign the data block digest; the vehicle terminal generates an anomaly audit log. The anomaly audit log may include the failure reason code, consistency metric value, threshold version identifier, window identifier, and necessary context digest.

[0086] In one embodiment, the anomaly audit record uses a structured set of fields, including at least: 1) Event Time: Timestamp of the refusal or the start and end timestamps of the application window; 2) Event types: refusal to sign, judgment failure, sampling anomaly, verification failure, counter anomaly, etc.; 3) Failure reason code: Used to quickly locate the cause of failure; 4) Decision reference fields: consistency metric value or its digest, threshold version identifier, and decision result bits; 5) Context reference fields: window identifier, monotonic counter reference information, challenge random number reference information (if present).

[0087] In one optional embodiment, the terminal triggers an integrity protection operation (including digital signature or message authentication code) on the summary of the anomaly audit record to generate an anomaly audit credential. The anomaly audit credential is used in disputed scenarios to prove that the terminal did indeed experience a rejection or anomaly event, and that this event is associated with a specific window identifier and counter reference information.

[0088] In an optional embodiment, abnormal audit records can be stored in an append-only manner, and chained summaries can be formed for the audit records (e.g., a summary of the previous record and the current record combined to form a summary) to enhance the detection capability of offline tampering.

[0089] 5.10 Challenge Random Number Binding and Server-Side Verification (see...) Figure 5 ) like Figure 5 As shown, the server can send a challenge nonce to the terminal to combat replay and middlebox forgery. The terminal incorporates the challenge nonce into the binding field when constructing the data block digest or credential digest, and includes the challenge nonce reference information in the status verification credential.

[0090] In one embodiment, the challenge random number carries a session identifier or batch identifier, and the server maintains its validity period and one-time use constraints; when the challenge random number is detected to be expired, duplicated, or does not match the window identifier, the server can determine that the verification has failed and record the failure reason code.

[0091] In one embodiment, after receiving the data block and status verification credentials, the server performs the following verification process: 1) Select the corresponding public key material based on the terminal identifier and key version identifier, and verify the signature value; 2) Verify whether the window identifier and the challenge random number reference information (if they exist) match the current session or the current batch; 3) Check whether the monotonic counter reference information satisfies the monotonic consistency constraint (e.g., no backtracking, no duplication); 4) Link and store verified documents with data blocks, and include rejected / abnormal audit documents in risk scoring or dispute resolution.

[0092] The server can also count the frequency of anomalies in the "terminal dimension / vehicle dimension"; when the frequency of anomalies exceeds the threshold, the challenge frequency can be increased, the window shortened, or the terminal can be required to report more verification fields (such as more metric summaries) to improve the robustness of the decision.

[0093] 5.11 Example of Failure Reason Code To enhance maintainability and verifiability, failure reason codes can be defined using an enumeration approach. The following is a non-restrictive example: 1) FR01: Physical side features are missing or sampling is abnormal; 2) FR02: Logic-side feature missing or sampling abnormal; 3) FR03: Time window alignment failed or timestamp is abnormal; 4) FR04: Consistency metric does not meet threshold (decision fails); 5) FR05: Threshold version mismatch or invalid configuration group; 6) FR06: The monotonic counter backs down, repeats, or does not satisfy monotonicity; 7) FR07: The challenge random number has expired, is duplicated, or does not match; 8) FR08: Security unit busy, denial of service, or signature failure; 9) FR09: Data block digest verification failed or digest algorithm identifier is not supported; 10) FR0B: Prediction consistency failure (e.g., digital twin / prediction model residuals exceed a threshold). 11) FR0A: Other unclassified anomalies.

[0094] In one embodiment, the failure reason code may further carry subcodes or parameters (e.g., FR04-1 indicates insufficient relevance, FR04-2 indicates constraint consistency failure) to provide more granular interpretability.

[0095] 5.12 Device Embodiment (corresponding to claim 2) In one embodiment, a vehicle data trusted generation device is provided, comprising: 1) Physical side acquisition module, used to acquire power supply voltage sequence and generate physical side features; 2) Logic-side acquisition module, used to collect logic-side features related to the vehicle's operating status; 3) Time alignment module, used to align physical and logical features within a preset time window; 4) Decision module, used to calculate consistency metrics and output consistency decision results, and generate failure reason codes in case of anomalies; 5) Summary construction module, used to construct a data block summary and include the window identifier, monotonic counter reference information, and challenge random number reference information (if present) into the binding fields; 6) Gated signature module (implemented by the security unit or in collaboration with the security unit) is used to perform digital signature on the digest to generate a state verification credential when the decision passes, and to refuse the signature when the decision fails; 7) Anomaly audit module, used to generate anomaly audit records when a signature is rejected or an anomaly occurs, and optionally triggers anomaly audit credentials; 8) Communication module, used to report data blocks, status verification credentials and / or anomaly audit credentials.

[0096] The above modules can be implemented by the processor executing programs in memory, or by hardware logic, programmable logic, firmware, or a combination thereof.

[0097] 5.13 Storage Medium Embodiment (corresponding to claim 3) In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the vehicle data trusted generation method described in this specification. The storage medium may be ROM, RAM, EEPROM, flash memory, hard disk, optical disk, or any combination thereof.

[0098] 5.14 Alternative Implementations and Extended Examples Without departing from the spirit of this invention, those skilled in the art can make various modifications or substitutions to this invention, for example: 1) Feature expansion: Physical side features can be expanded to include current waveforms, temperature, vibration, etc.; logical side features can be expanded to include acceleration, braking status, gear status, etc. 2) Decision extension: Consistency decisions can adopt multi-metric fusion or hierarchical decision-making (e.g., first perform basic constraint consistency, and then perform correlation decision). 2-1) Decision extension (optional): Execute a lightweight digital twin / predictive model within the security component and participate in consistency decisions based on the predictive residuals; 3) Gated extension: Gated signatures can sign data block digests directly, or they can sign combined digests of "data block digest + decision reference field"; 4) Audit extension: Anomaly audits can selectively record context summaries to balance storage and verifiability.

[0099] VI. Examples and Recommendations for Verifiable Experiments To verify the effectiveness of this invention, the following non-limiting experiments can be conducted: 1) Bench injection experiment: Using a regulated power supply / signal source and CAN playback to construct a fake input, verify that the consistency judgment and rejection path can output failure reason codes, and optionally generate abnormal audit vouchers; 2) Real-vehicle statistical experiment: Samples were taken under different vehicle models and operating conditions to statistically analyze the range of change in false rejection rate and false pass rate, and to evaluate the adaptation effect of dynamic threshold; 3) Comparative experiment: Compare the evidentiary differences of the "ungated signature" scheme in replay / injection scenarios (e.g., whether verifiable audit evidence of refusal to sign can be formed). 4) Counter rollback experiment: Try resetting the terminal storage and replaying the old window to verify that the server can identify anomalies and record the corresponding failure reason codes through the monotonicity of the counter; 5) Intermediate box replication experiment: Insert an intermediate box between the OBD port and the terminal, attempt to replicate the challenge session and replay historical data blocks, and verify that binding the challenge random number can reduce the replication success rate; 6) Threshold drift experiment: Samples were taken under different battery health conditions and temperature conditions to verify that the threshold version identifier and parameter iteration mechanism can support interpretation and verification.

[0100] To further illustrate the feasibility of this invention, several more specific embodiments and engineering details are provided below. Those skilled in the art should understand that these details are intended to enhance the sufficiency of disclosure and facilitate verification, and do not constitute a limitation on the scope of protection of this invention.

[0101] 6.1 Example 1: Basic Gated Signature (No Challenge Random Number) In one embodiment, the terminal executes the gating signature process without real-time interaction, which is suitable for scenarios where network coverage is unstable or there is a delay in reporting.

[0102] 6.1.1 End-side process (example) The terminal completes sampling and decision-making within the window $W_k$ and constructs the data block to be reported. The following steps (example) can be used: S201: Initialize window parameters ($T_w$, $T_s$, sampling rate, logical side field list) and threshold version identifier; S202: Collect the power supply voltage sequence within the window $W_k$ and extract the physical side feature set $P_k$; S203: Collect the logical side feature set $L_k$ within the window $W_k$ and record the source identifier and availability flag; S204: Perform time alignment on $P_k$ and $L_k$, calculate the consistency metric $m_k$, and obtain the decision result $j_k$; S205: Read the monotonic counter reference information $ctr_k$ and construct the window identifier $wid_k$; S206: Perform normalized encoding on the field set to obtain the encoding result $enc_k$, and calculate the digest $h_k$; S207: If $j_k$ If the preset conditions are met, the security unit is requested to sign $h_k$ to obtain the signature value $sig_k$ and generate the status verification credential $v_k$; otherwise, the signature is rejected and an abnormal audit record $a_k$ is generated; S208: Write the data block, credential / audit record to local storage and report it when communication is available.

[0103] 6.1.2 Standardized Coding and Summary Input (Example) To mitigate the risk of digest inconsistencies caused by field expansion, in one embodiment, the digest input uses TLV encoding. Example fields are as follows (field names are for illustrative purposes only): 1) T01: Terminal ID or its anonymized representation; 2) T02: Window ID or window start and end timestamps; 3) T03: Monotonic counter reference information (CounterRef); 4) T04: Physical Features set or its summary; 5) T05: Logical Features or its summary; 6) T06: DecisionRef field, including threshold version identifier, consistency metric or its digest, decision bits, etc.; 7) T07: DigestSpecVersion.

[0104] In one embodiment, to facilitate server recalculation and cross-implementation consistency verification, field canonical encoding may at least follow the following minimum rules (not limited): 1) Field order: Output in ascending order by field number (e.g., T01..T07); the same field number is not allowed to appear multiple times; array / vector fields are encoded in a fixed element order; 2) Missing semantics: Distinguish between Absent (field missing / unavailable) and Null (field exists but has an empty value); Absent is explicitly declared by a missing bitmap or source status marker, while Null is encoded using a fixed type code to avoid semantic confusion between "omitted field" and "empty field"; 3) Numerical quantization: Numerical fields such as vehicle speed / voltage / mileage are encoded after being encoded using the units and scaling (fixed-point) agreed upon in the field dictionary; rounding rules (such as rounding to the nearest zero, etc.) are specified by DigestSpecVersion to avoid inconsistencies in the summary caused by differences in floating-point representation; 4) Time normalization: Timestamps are standardized to a preset baseline and precision (e.g., UTC epoch in milliseconds), and a fixed pruning / rejection strategy is implemented for out-of-bounds values; 5) Byte order and length: Fixed-length values ​​use a conventional byte order (e.g., big-endian), and the length L uses a fixed unsigned representation; non-deterministic encoding (e.g., variable-length leading zeros, unordered key-value pairs) is prohibited. 6) Version Binding: DigestSpecVersion is required. The server restores the field set, order, missing representation and quantization rounding rules according to this version, thereby achieving "recalcifiable consistency".

[0105] In one embodiment, the digest algorithm may be SHA-256, SM3, or an equivalent digest algorithm. The terminal writes the digest algorithm identifier into the credential or audit record so that the server can verify it.

[0106] 6.1.3 Anomaly Audit Log Structure (Example) When a rejection path is triggered, the abnormal audit record can use a structured set of fields: 1) Event type (e.g., RejectSign, AlignFail, MetricLow, CounterRollback, etc.); 2) Failure reason code and subcode; 3) Decision reference fields ($m_k$, threshold version identifier, decision bit); 4) Contextual reference fields ($wid_k$, $ctr_k$, source availability tag digest); 5) Optional device runtime summary (e.g., firmware version, configuration version, clock skew status).

[0107] In one embodiment, abnormal audit records are stored in an append-only manner, and chained summaries can be generated for the audit records to facilitate the subsequent detection of offline tampering.

[0108] 6.2 Example 2: Gated Signatures Bound by Challenging Random Numbers (Online Interaction) In one embodiment, the server periodically or on demand issues challenge random numbers, and the terminal binds the challenge random numbers when generating credentials to improve its ability to resist cross-session replay and middlebox replication.

[0109] 6.2.1 Challenging Random Number Formats and Lifecycles (Example) The challenge random number can contain the following fields (example): 1) Nonce: The main body of the random number; 2) SessionID: Session identifier or batch identifier; 3) ExpireAt: Expiry date timestamp or number of valid windows; 4) PolicyID: Challenge strategy identifier (e.g., challenge once every N windows, or challenge triggered by risk).

[0110] The server can maintain "used Nonce sets" or "session window mappings" to prevent the same Nonce from being reused in different windows or on different terminals.

[0111] 6.2.2 End-side state machine (example) To facilitate engineering implementation, the terminal can use a state machine to manage the challenge of random numbers: 1) Idle: No valid challenge; 2) NonceReady: A valid challenge exists (unused); 3) NonceBound: The challenge has been bound to a window summary; 4) NonceExpired: The challenge has expired. 5) NonceRejected: The server reports that the challenge does not match or is duplicated.

[0112] In one embodiment, when NonceExpired or NonceRejected, the terminal enters a degradation strategy: continue generating credentials without a Nonce (if allowed), or generate an abnormal audit log and wait for a new challenge.

[0113] 6.2.3 Binding Strategy (Example) In one embodiment, the terminal writes the Nonce and SessionID as binding fields into the digest input; in another embodiment, the terminal only writes a digest or reference information of the Nonce to reduce the plaintext length.

[0114] In addition to verifying the signature, the server can also verify the following during signature verification: 1) Is the Nonce still valid? 2) Does the Nonce correspond to the SessionID? 3) Does the Nonce match the window identifier mapping? 4) Whether the same Nonce is used repeatedly.

[0115] 6.3 Example 3: Iterative Version of Dynamic Threshold and Preset Conditions In one embodiment, to adapt to different vehicle models and different electrical environments, the terminal uses dynamic thresholds or multi-configuration group thresholds, and achieves interpretable grayscale iteration through version identifiers.

[0116] 6.3.1 Configuration Groups and Version Identifiers (Example) The terminal can maintain multiple threshold configurations (PolicySets), each with a unique version identifier, PolicyVer. A PolicySet can contain: 1) Sampling rate, window length, and step size; 2) Physical side feature selection and parameter extraction (e.g., frequency domain bandwidth, filtering parameters); 3) Logical side field set and source priority; 4) Consistency measurement type, combination method, and threshold parameters; 5) Rejection / downgrade strategy parameters and reason code mapping table.

[0117] In one embodiment, PolicyVer can be issued with a server signature, and the terminal verifies the configuration signature before enabling it, thus preventing attackers from reducing the gating strength by tampering with the configuration.

[0118] 6.3.2 Dynamic Threshold Generation (Example) The terminal can locally maintain the statistics of the most recent $N$ passing windows and generate dynamic thresholds. To prevent attackers from polluting the statistics by forging "passing windows" for a short period of time, the following unrestricted strategy can be adopted: 1) Update statistics only if there are consecutive successes and the source availability meets the criteria; 2) Set the maximum update rate for statistical updates; 3) Freeze the dynamic threshold and revert to the conservative threshold when an abnormally high frequency occurs; 4) Write the dynamic threshold parameter version and freeze / rollback events to the audit log.

[0119] 6.4 Server-side evidence storage, verification, and policy feedback In one embodiment, after receiving the data block and credentials, the server stores them and performs verification and policy feedback.

[0120] 6.4.1 Evidence Storage Data Structure (Example) The server can store the following structured records (example): 1) EvidenceRecord: Terminal identifier, window identifier, reception time, digest value, signature value, key version identifier, PolicyVer, and decision reference field; 2) DataBlockStore: Data block in its original or compressed form (optional), or simply stores a set of verifiable fields; 3) AuditRecord: Abnormal audit records and abnormal audit credentials (if they exist), as well as server review results.

[0121] In one embodiment, the server indexes the EvidenceRecord to enable rapid retrieval by terminal, vehicle, and time window, and supports batch review of disputed time periods.

[0122] 6.4.2 Verification Algorithm and Exception Stratification (Example) Server review may include at least: 1) Signature verification: Verify the signature value using the public key corresponding to the terminal; 2) Counter verification: Check whether the monotonic counter reference information satisfies the monotonicity and non-repetition constraints; 3) Challenge Validation: If a Nonce reference exists, validate the validity of the Nonce and the one-time constraint; 4) Policy consistency: Check if PolicyVer is within the allowed range, and trigger policy updates if necessary.

[0123] The server can perform tiered processing based on the failure reason code and the review results, for example: 1) Minor anomalies: Simply reduce the weight of the data in that window, or mark it as "low confidence"; 2) Suspicious anomalies: Increase the frequency of challenges, requiring additional verification fields or triggering secondary sampling; 3) High-risk anomalies: trigger manual review, freeze the terminal, or issue stricter policies.

[0124] 6.4.3 Strategy Feedback (Example) The server can issue policy feedback based on the terminal anomaly statistics results: 1) Issue a new PolicySet version; 2) Adjust the window length and sampling rate; 3) Adjust the frequency of random challenge numbers being generated; 4) Enable stronger gating combination metrics.

[0125] 6.5 Security Unit Key Management, Device Registration and Revocation In one embodiment, the terminal completes the writing of key materials and certificate binding during the factory or registration stage.

[0126] 6.5.1 Device Registration (Example) The device registration process may include: 1) The terminal generates or imports a signature key pair, and the private key is stored in a non-exportable area of ​​the secure unit; 2) The terminal submits a public key and a device attribute digest (e.g., hardware version, firmware version, manufacturing batch digest) to the server. 3) The server completes the binding and generates a certificate chain or key version identifier, then sends it back to the terminal; 4) The terminal writes the certificate chain identifier and key version identifier into the local configuration and references them in the credentials.

[0127] 6.5.2 Revocation and Usage Restrictions (Example) In one embodiment, the server can revoke the key version identifier. After revocation, the terminal can still retain the "audit-type signature capability" while disabling the "business-type signature capability" usage restriction policy, so that abnormal audit credentials can still be generated for evidence during risk mitigation.

[0128] In one embodiment, the usage restriction policy can be implemented through a "UsageTag": the same security unit contains keys for different purposes or the same key under different authorization states, which restrict the types of digests that can be signed; when the terminal requests a signature, it carries the UsageTag, and the security unit decides to allow or deny it based on the authorization state.

[0129] 6.6 Performance, Bandwidth, and Storage Overhead (Example) The gated signature of this invention targets both digest and structured reference fields, achieving a balance between evidentiary value and resource overhead.

[0130] In one embodiment, the window length $T_w$ can be selected from several seconds to tens of seconds, and the step size $T_s$ can be less than or equal to $T_w$. When the step size is small and causes window overlap, duplicate statistics can be avoided by recording the window number and overlap strategy identifier in the data block.

[0131] In one embodiment, the terminal may employ the following optimizations to reduce overhead: 1) The original voltage sequence is not fully reported; only physical-side characteristics and necessary summaries are reported. 2) Perform differential coding or sampling based on importance for logical-side fields; 3) Only a summary signature is used for audit logs, not a full context signature; 4) Use a circular buffer for local storage and set critical rejection events as an overwriteable area (preferred).

[0132] In one embodiment, if the security unit signing process is time-consuming or consumes a lot of power, the signing request can be queued and a timeout policy can be set; when the security unit is busy and a timeout occurs, a corresponding failure reason code FR08 can be generated, and the process can be retried in a subsequent window.

[0133] 6.7 Consistency Measure Fusion and Anti-Avoidance Design (Example) In one embodiment, to reduce the risk of attackers circumventing a single metric, consensus decisions can employ multi-metric fusion. Multi-metric fusion can be achieved through methods such as weighted summation, voting, hierarchical decision-making, or confidence interval constraints.

[0134] 6.7.1 Layered Decision (Example) Layered decision-making can include two categories: the first layer, "consistency of basic constraints," and the second layer, "consistency of statistics."

[0135] 1) First-level constraint consistency: Verify whether the logic side and the physical side meet the basic engineering constraints. For example, when there is a significant acceleration / high load change on the logic side, there should be at least an explainable ripple / harmonic change on the physical side. If it remains unchanged for a long time or the change direction is opposite, it is judged as inconsistent. 2) Second-level statistical consistency: After passing through the first level, statistical measures such as correlation, mutual information, and sequence similarity are calculated to give more granular confidence results.

[0136] The advantages of layered decision-making are: the first layer of constraints can capture attacks with "obvious inconsistencies" with relatively low computational overhead, while the second layer of statistical measures is used to distinguish between "minor biases caused by natural noise" and "suspicious systematic biases". Terminals can write the "layered decision result reference field" into vouchers or audit logs for easy server review.

[0137] 6.7.2 Multiple Thresholds and Grayscale (Example) In one embodiment, the terminal can set multiple threshold levels: 1) Strong pass threshold: If the threshold is met, a highly reliable credential is generated; 2) Weak pass threshold: If the threshold is met, a low-trust credential is generated or a trust level flag is set in the credential; 3) Rejection threshold: If the threshold is not met, the application will be rejected and an abnormal audit record will be generated.

[0138] The aforementioned trust level markers can be used on the server side for tiered processing (e.g., direct data entry, delayed data entry, or triggering supplementary audits).

[0139] 6.8 Voltage Sampling Circuit and Sampling Quality Control (Example) In one embodiment, the voltage sampling circuit includes a voltage divider network, an anti-aliasing filter, an analog-to-digital converter (ADC), and a sampling clock. To improve the verification value of physical-side features, the terminal can perform self-checks on the sampling quality and write audit data.

[0140] 6.8.1 Sampling Rate and Filtering (Example) The sampling rate can be selected based on the vehicle's electrical noise characteristics and processor capabilities. In one embodiment, the terminal first performs low-pass or band-pass filtering on the voltage sequence to suppress high-frequency noise and highlight frequency bands related to the engine / load; filter parameters and version identifiers can be written into the PolicySet.

[0141] 6.8.2 Calibration and Drift (Example) In one embodiment, the terminal performs periodic calibration of the ADC zero point and gain. The calibration can be performed in a non-limiting manner as follows: 1) Collect baseline voltage during low-interference periods such as when the vehicle is stationary or off, and update the zero-point offset; 2) Perform gain calibration using a known reference voltage or an internal reference source; 3) Write the calibration version and calibration timestamp summary into the audit log.

[0142] When sampling saturation, undersampling, excessive jitter, or timestamp errors are detected, the terminal can trigger failure reason codes FR01 / FR03 and enter the rejection or downgrade path.

[0143] 6.9 Source Identification and Reliability Control of Logical Side Fields (Example) In one embodiment, the logical-side fields may originate from the OBD PID, raw CAN message parsing, or other sensors. To mitigate the risk of a "single point of forgery," the terminal can set source priority and cross-validation strategies for each logical-side field.

[0144] 6.9.1 Source Identifier (Example) The terminal can record the following source identifiers: 1) SourceType: OBD_PID, CAN_FRAME, GNSS, IMU, etc.; 2) SourceID: PID number, CAN ID, sensor model, etc.; 3) SourceStatus: Available / Timeout / Verification Failure, etc. 4) ParseVer: Parses the configuration version or DBC version.

[0145] In one embodiment, if the source status of the logical side field is abnormal (e.g., continuous timeout, CRC check failure, parsing configuration mismatch), the exception is written to the failure reason code FR02, and the "availability decay coefficient" can be output for the consistency decision.

[0146] 6.9.2 Multi-source consistency (example) Taking vehicle speed as an example, the terminal can use the vehicle speed from the OBD PID and the speed calculated by GNSS simultaneously for cross-verification; when the long-term deviation between the two exceeds the threshold, it can trigger anomaly auditing or increase the challenge frequency.

[0147] 6.10 Data Block Segmentation, Compression, and Intermittent Network Reporting (Example) In one embodiment, to adapt to intermittent cellular network coverage and weak coverage, the terminal can report data blocks and credentials separately.

[0148] 1) First, report the summary and status verification certificate (smaller packets preferred) so that the server can quickly store the certificate; 2) When network conditions permit, report the complete data block or supplementary field set; 3) If the complete data block fails to be reported, it can at least be guaranteed that the "verifiable summary and reference fields" have been stored.

[0149] In one embodiment, the terminal performs compression on the complete data block (e.g., dictionary compression or differential encoding) and indicates the compression format in the digest specification version identifier.

[0150] 6.11 Dispute Review and Audit Request Interface (Example) In one embodiment, when a dispute review or risk control review is required, the server can initiate an audit request to the terminal or data storage system based on the stored evidence records.

[0151] 6.11.1 Audit Request Fields (Example) An audit request may include: 1) The disputed period (start and end times or the range indicated by the window); 2) Target field set (e.g., logical-side fields or physical-side features that need to be supplemented). 3) Review level (e.g., review only signatures and counters, or review multi-source consistency). 4) Audit request identifier and authorization information (optional).

[0152] The terminal can decide whether to output supplementary fields based on the authorization information, and write the audit request identifier into the abnormal audit record or supplementary reporting record for traceability.

[0153] 6.11.2 Review Steps (Example) The server can execute the following during dispute review: 1) Verify each document in the dispute window, checking the PolicyVersion and Summary Specification Version; 2) Check the monotonicity of the counter and the continuity of the window; 3) Perform a consistency recalculation on the supplementary fields and write the recalculation results into the review report.

[0154] 6.12 Device-side implementation pseudocode (example) In one embodiment, the terminal can implement gated signature as shown in the following pseudocode (illustrated): 1) CollectPhysical(); CollectLogical(); Align(); 2) metric = ComputeMetric(P, L, PredResidual_optional); decision =Compare(metric, threshold); 3) wid = MakeWindowId(); ctr = ReadMonotonicCounter(); 4) digestInput = EncodeTLV(wid, ctr, P_summary, L_summary,DecisionRef, SpecVer, NonceRef_optional); 5) h = Hash(digestInput); 6) if decision == PASS: sig = SecureElementSign(h); EmitVoucher(sig,wid, ctr, NonceRef_optional, DecisionRef); 7) else: audit = MakeAuditRecord(reasonCode, metric, thresholdVer,wid, ctr, NonceRef_optional, ModelVer_optional, FeatureSetVer_optional,PredResidual_optional); EmitAudit(audit); OptionalSignAuditSummary(); The pseudocode above is used to illustrate the process and does not limit the specific implementation language and data structure.

[0155] 6.13 Key Field Dictionary, Coding Standards, and Examples (Further Explanation) To further enhance "verifiable consistency" and "cross-version interpretability," in one embodiment, the terminal and server establish a unified dictionary convention for key fields of data blocks, vouchers, and audit records. It should be understood that the following fields are for illustrative purposes only and do not limit the number, order, or names of fields.

[0156] 6.13.1 Data Block Field Dictionary (Example) Data blocks are used to carry raw or extracted information within a window. To reduce bandwidth overhead, in one embodiment, data blocks may be divided into "required fields" and "optional fields".

[0157] The definitions of terms such as EvidenceId, AckCode, and CounterRef can be found in version 5.0.

[0158] Required fields may include: 1) TerminalID: Terminal identifier or its anonymized representation; 2) VehicleRef: Vehicle identification reference information (e.g., VIN summary, vehicle binding number summary), used for server-side association; 3) WindowID: Window identifier $wid_k$; 4) WinTime: Window start and end timestamps or relative time base; 5) CounterRef: Monotonic counter reference information $ctr_k$; 6) PolicyVer: Preset condition version identifier (threshold / parameter version); 7) SpecVer: Summary specification version identifier (field encoding rule version); 8) DecisionRef: Decision reference field (metric or its summary, decision bits, hierarchical decision result, etc.).

[0159] Optional fields may include: 9) Physical Features: Set of physical features (e.g., ripple amplitude, peak frequency, harmonic energy, undervoltage duration, number of abrupt changes, etc.). 10) LogicalFeatures: A collection of logical-side fields (e.g., vehicle speed, RPM, mileage increment, throttle / brake status, etc.). 11) SourceMeta: Source identifier and availability metadata (SourceType, SourceID, SourceStatus, ParseVer, etc.); 12) NonceRef: Challenge random number reference information (if enabled); 13) CompressMeta: Compressed / chunked metadata (if enabled).

[0160] 14) ModelVer: Predictive model / digital twin model version identifier (if enabled); 15) FeatureSetVer: The version identifier of the model input feature set (if enabled); 16) PredResidual: Predicted residual quantization, residual vector summary, or its reference information (if enabled).

[0161] In one embodiment, to facilitate alignment between engineering implementation and review, the field dictionary can use the following minimal template to record key field attributes (example, not a limitation): In one embodiment, to avoid ambiguity regarding the same conceptual field across different manufacturers / firmware, the field dictionary can define conventions for "data type, unit, range, and expression of missing values." For example, vehicle speed is expressed in km / h; if a value is missing, it is set to null and the reason for the missing value is marked in SourceStatus; the physical characteristic unit for voltage sampling is V or its normalized representation.

[0162] 6.13.2 Status Verification Credential Field Dictionary (Example) Status verification credentials are used to carry verifiable signature information, preferably in a small packet structure. Their fields may include: 1) Sig: Signature value; 2) SigAlg: Signature algorithm identifier (e.g., SM2, ECDSA, etc.); 3) KeyVer: Key version identifier or certificate chain identifier; 4) VoucherTS: Voucher generation timestamp (can be local time, time after synchronization, or relative time). 5) WindowIDRef: Window identifier reference; 6) CounterRef: A reference to a monotonic counter; 7) PolicyVerRef: Policy version reference; 8) NonceRef: A reference to the challenge random number (if enabled); 9) DecisionRef: The field referencing the decision (or its summary); 9-1) ModelVerRef: Version identifier reference for the prediction model / digital twin model (if enabled); 9-2) FeatureSetVerRef: Version identifier reference for the model input feature set (if enabled); 9-3) PredResidualRef: Quantized value of the prediction residual, summary of the residual vector, or its reference information (if enabled); 10) Digest: The signed digest value $h_k$ (optional; the plaintext field can be omitted if it is already included in the message covered by Sig).

[0163] In one embodiment, the credentials may also include a trust level marker (e.g., StrongPass / WeakPass) or a risk marker (e.g., NeedReview) for tiered processing on the server side.

[0164] 6.13.3 Dictionary of Fields for Anomaly Audit Records (Example) Anomaly audit logs are preferably structured sets of fields and can be generated immediately upon rejection or anomaly occurrence to avoid evidentiary gaps caused by "post-anomaly recording." Anomaly audit logs may include: 1) AuditTS: Audit event timestamps; 2) WindowIDRef: Window identifier reference; 3) CounterRef: A reference to a counter; 4) FailReason: Failure reason code and subcode; 5) MetricRef: The metric or its summary, threshold version identifier; 6) SourceMetaRef: Source status summary; 7) DeviceStateRef: A summary of the device's running state (firmware version, configuration version, temperature range, voltage range, clock drift state, etc.); 8) NonceRef: A reference to the challenge random number (if enabled); 9) AuditChainRef: Chained summary reference (previous audit summary, etc., optional).

[0165] In one embodiment, the abnormal audit credential signs the "audit summary". The audit summary may include key reference fields such as FailReason, WindowIDRef, CounterRef, PolicyVer, and MetricRef to achieve a closed loop of rejection evidence for "small packages that can be verified".

[0166] 6.14 Secure Element Signature Interface, Authorization Policy, and Anti-Abuse Controls (Further Explanation) In one embodiment, to prevent attackers from exhausting resources or circumventing gating logic by frequently triggering signature requests, a "signature interface with authorization context" can be used between the terminal and the security unit.

[0167] 6.14.1 Signature Request Context (Example) A signature request can carry the following context parameters: 1) Digest: The digest value to be signed; 2) UsageTag: Purpose identifier (business voucher / audit voucher / maintenance diagnostics, etc.); 3) WindowIDRef and CounterRef: Window and counter reference information (optional, if secondary constraints are required within the security cell); 4) PolicyVer: Policy version; 5) RateClass: Request rate level or priority (e.g., normal window / high-risk window).

[0168] In one embodiment, the security unit can implement whitelist control for UsageTag, allowing signatures only for requests that conform to gating logic and are triggered by trusted firmware.

[0169] 6.14.2 Rate Limiting and Resource Conservation (Example) The security unit can maintain a signature rate counter or time window to limit the number of signatures per unit time. When an abnormally high frequency request is detected, it can refuse to sign and return the corresponding failure reason code (e.g., FR08), ​​while the terminal writes the event to the anomaly audit log. This mechanism reduces the risk of attackers using "high-frequency signatures" for offline enumeration or exhaustive attacks.

[0170] 6.14.3 Signature materials and certificate chain reference (example) In one embodiment, the terminal only references the KeyVer or certificate chain identifier in the credential, and the server retrieves the corresponding public key material and verifies the signature based on the KeyVer. If key rotation is enabled, the terminal can carry a list of allowed KeyVers in the PolicySet and write an audit record during key rotation to avoid traceability difficulties caused by "old keys continuing to generate business credentials".

[0171] 6.15 Monotonic Counters, Window Continuity, and Offline Retransmission Strategies (Further Explanation) In one embodiment, the monotonic counter is used not only for replay protection but also for "window continuity verification." The server can identify gaps and abnormal jumps based on the counter sequence, thereby quickly locating "missing windows" and "suspicious rollbacks" in disputed scenarios.

[0172] 6.15.1 Atomicity of Counter Updates (Example) The terminal preferably adopts an "atomic increment after successful signature" update strategy: the terminal updates $ctr_k$ to $ctr_{k+1}$ only if the security unit returns a successful signature. If the update fails (e.g., a power outage causes a write failure), the terminal generates an exception audit record in the next window and marks it as FR06 to prevent the server from mistakenly treating the duplicate counter as normal.

[0173] 6.15.2 Window Gaps and Re-transmission (Example) In intermittent network scenarios, the terminal can cache data blocks and credentials for multiple windows and re-transmit them in counter order after the network is restored. The server can verify in CounterRef order: 1) If the counter is continuous and the signature verification is successful, mark the window as having been stored; 2) If a gap occurs, the terminal can be requested to transmit the audit summary or necessary fields of the corresponding window; 3) If a rollback or repetition occurs, record FR06 and increase the challenge frequency or proceed to manual review.

[0174] To avoid duplicate reporting caused by network jitter and resulting in duplicate counting on the server side, in one embodiment, the terminal constructs a unified idempotent key, EvidenceId, for each window credential. The EvidenceId can be obtained by deterministically encoding the terminal identifier reference, WindowIDRef, CounterRef, NonceRef (if enabled), and digest specification version identifier, and then calculating the digest. The terminal carries the EvidenceId or its reference information during retransmission. The server performs idempotent deduplication using the EvidenceId and returns an acknowledgment code, AckCode. The acknowledgment code includes at least: OK (first reception) and OK_DUP (duplicate received), and optionally includes RETRY (server temporarily unable to process or triggering rate limiting, retry recommended; optionally carrying suggested retry time or backoff parameters) and / or REJECT (signature verification failed, format mismatch, or missing key fields, etc.; optionally carrying rejection reason code RejectReason, field name example is rejection_reason). When the terminal receives OK_DUP, it marks the corresponding cached record as completed and evicts it according to the policy to avoid offline cache bloat.

[0175] In some embodiments, the above receipt can be fielded as a receipt message Ack (example fields are shown in the table below): The terminal performs exponential backoff for ack_code=RETRY and retains offline records, and records rejection_reason for ack_code=REJECT and stops automatic retries or triggers audit handling (optional). In some embodiments, rejection_reason can be an enumeration code (non-limited), such as: RR01 Signature verification failed; RR02 Format mismatch; RR03 Key field missing; RR04 Version not supported; RR05 Counter abnormality.

[0176] 6.16 Timestamps, Time Synchronization Mechanisms, and Interpretable Time Trustworthiness (Further Explanation) In one embodiment, timestamps are both an important component of the chain of evidence and a potential attack surface (e.g., creating a seemingly plausible timeline by tampering with the system time). Therefore, terminals can employ a time management strategy of "multi-source time synchronization + drift interpretability".

[0177] 6.16.1 Time synchronization source and time synchronization identifier (example) Time synchronization sources can include: cellular network time, server-sent time, GNSS time, or a local monotonic clock. The terminal can record this in DeviceStateRef: 1) TimeSource: Time synchronization source type; 2) TimeSyncAge: The time span since the last time synchronization; 3) TimeSkew: Estimated clock skew range; 4) TimeState: Time is synchronized / not synchronized / excessive drift, etc.

[0178] In one embodiment, when TimeSkew exceeds a threshold, the terminal may lower its trust level or enter a rejection / audit path, and write the corresponding reason code into the audit log so that the server can explain "why the trust level decreased during this period".

[0179] 6.16.2 Relative Time and Window Number (Example) In one embodiment, even if absolute time is unreliable, the terminal can still use a monotonic counter and window number to form a relative timeline: the combination of window number $k$ and counter $ctr_k$ can be used on the server side to reconstruct the event sequence; if time synchronization is subsequently restored, a "time synchronization correction point" can be provided in subsequent records, and the server can use this to perform timeline correction on the historical window (not mandatory).

[0180] 6.17 Attack Scenario Coverage, Key Evidence Points, and Failure Reason Code Mapping (Further Explanation) To enhance the evidentiary value of the patented solution, in one embodiment, the terminal establishes a "scenario-evidence-reason code" mapping table for common attack or abnormal scenarios.

[0181] 6.17.1 Mapping from Scene to Evidence Loop (Example) 1) Bench playback / simulator: The physical side characteristics and logical side characteristics are inconsistent for a long time, triggering FR04; the audit log contains MetricRef, PolicyVer, and SourceMetaRef; 2) CAN Injection / Replay: If an unreasonable jump occurs in the logical side field or is inconsistent with multi-source verification, FR02 / FR04 is triggered, and the abnormal source status can be recorded; 3) Unplug / Power-off Interference: When window continuity is disrupted or counter updates abnormally, FR06 is triggered, and a summary of the power-off event can be recorded; 4) Intermediate box replication: Challenge random number reuse or session mismatch triggers FR07; audit logs contain NonceRef and SessionID references; 5) Low-quality sampling / hardware failure: Voltage sampling saturation or timestamp abnormality triggers FR01 / FR03.

[0182] 6.17.2 Priority of Evidence Preservation (Example) In one embodiment, the terminal sets evidence preservation priorities for different events: 1) High priority: Audit summaries and abnormal audit documents for events such as counter rollback, challenge duplication, and intermediate box suspicion (preferably non-coverable); 2) Medium priority: Events with slightly low consistency metrics, occasional missing sources, etc. (can be covered but statistics are retained); 3) Low priority: transient anomalies caused by slight noise (only aggregate statistics are retained).

[0183] 6.18 Manufacturing, Assembly, Maintenance, and Traceability Processes (Further Explanation) In one embodiment, to ensure that "signature credentials are traceable to specific hardware entities", the manufacturing, assembly, and maintenance processes can be combined with key material management.

[0184] 6.18.1 Factory Injection and Consistency Verification (Example) The terminal can execute the following commands at the factory: 1) Inject or generate key pairs into the secure element; 2) Record the manufacturing batch summary, hardware version, firmware version, and generate a ManufacturingRef; 3) The server registers the binding relationship between TerminalID, KeyVer, and ManufacturingRef; 4) Perform a self-test window sampling and signing to verify that the signature link is available.

[0185] 6.18.2 Maintenance, Replacement, and Key Rotation (Example) When a terminal is replaced or repaired, the server can initiate a key rotation and revoke the old KeyVer. During the rotation window, the terminal can continue to generate audit credentials to record abnormal events during the rotation process, but business credentials can be restricted or downgraded according to policies to reduce the risk of "abuse during the maintenance phase".

[0186] 6.19 Parameter Range, Default Recommendations, and Alternative Implementations (Further Explanation) In one embodiment, the window and sampling parameters can be selected from the following ranges: 1) Window length $T_w$: 2s~60s (preferably 5s~20s); 2) Step size $T_s$: 1s~$T_w$ (preferably not greater than $T_w$, to control the degree of overlap); 3) Voltage sampling rate: 50Hz~5kHz (can be selected according to hardware capabilities and noise frequency band); 4) Logic side sampling rate: 1Hz~100Hz (selected according to field type and bus load); 5) Challenge issuance frequency: once every N windows or triggered by risk (e.g., increase challenge frequency when abnormal frequency increases).

[0187] In one embodiment, if the vehicle's power supply noise is weak, resulting in insufficient physical-side feature distinguishability, current sampling, ignition wire status, or other interpretable physical quantities can be introduced as supplementary physical-side features. If logical-side fields are limited, a more reliable source can be selected (e.g., directly reading the ECU mileage increment, or introducing GNSS / IMU multi-source verification). All of the above alternative implementations do not deviate from the core idea of ​​"physical-side and logical-side cross-constraints + gated signatures + closed-loop rejection auditing."

[0188] 6.20 Explainable Reports and Dispute Review Outputs for End-to-End Cloud Collaboration (Further Explanation) In one embodiment, the server can generate an "interpretable review report" based on stored records for dispute resolution and compliance auditing. The review report may include: 1) List of windows, counter sequence, and gap markers during the disputed period; 2) Verification results, PolicyVer, and KeyVer for each window; 3) Interval statistics for consistency measures (e.g., percentage of successful applications, percentage of weak successful applications, percentage of rejected applications). 4) Distribution and temporal clustering of failure reason codes (e.g., whether they occur in clusters after a particular plug-in / plug-out or power outage). 5) If challenge random number is enabled, list the session mapping and the one-time verification result of Nonce.

[0189] Through the aforementioned reports, the server can provide interpretable conclusions on key issues such as whether data has undergone gated signature, why it was rejected, whether anomalies are concentrated, and whether counters are continuous, without relying on "subjective judgment" or "only looking at the reasonableness of field values," thereby improving the efficiency of evidence collection and operation and maintenance.

[0190] 6.21 Set of Implementable Algorithms and Combinatorial Strategies for Consistency Measures (Further Explanation) In one embodiment, the consistency metric $m_k$ can be obtained by combining multiple sub-metrics to adapt to different vehicle models, electrical environments, and resistance levels. Sub-metrics can include, but are not limited to, the following types.

[0191] 6.21.1 Relevance / Similarity Measures (Example) In one embodiment, if the logical-side field is a time-varying sequence such as vehicle speed, rotational speed, or load, a correlation measure between it and the physical-side feature sequence can be constructed. For example: 1) Within the window $W_k$, normalize a certain feature sequence $p_k(t)$ on the physical side and a certain feature sequence $l_k(t)$ on the logical side, and then calculate the correlation coefficient $\rho_k$. 2) If the sampling rates are different, interpolate or segment and align the sequences with lower sampling rates before calculating $\rho_k$; 3) After calculating the correlation of multiple feature pairs $(p_i,l_j)$ respectively, $m_k$ is synthesized in a weighted manner.

[0192] In one embodiment, to combat misjudgments caused by "overall translation or scaling", the sequence can be processed by removing the mean, trend, or standardization before calculating the correlation, and the processing method and version identifier can be recorded in the PolicySet for interpretation.

[0193] 6.21.2 Constraint Consistency Measures (Example) In one embodiment, the terminal maintenance engineering constraint set $\mathcal{C}$ is used to express the interpretable relationship between logical-side changes and physical-side changes. The constraints may include: 1) Event triggering constraints: For example, when the "engine start / idle speed stabilize / accelerate" event occurs on the logic side, the ripple energy or harmonic structure on the physical side should show changes that conform to experience; 2) Range constraints: For example, when the vehicle speed on the logic side is 0 for a long time and the engine is not started, the physical side should not continuously exhibit high-speed, high-load ripple characteristics; 3) Rate of change constraint: For example, if the mileage increment on the logical side is 0, and the physical side is consistent with the high load mode of the engine for a long period of time, it is suspicious.

[0194] In one embodiment, the constraint consistency metric may consist of the "percentage of constraints satisfied," the "severity of constraints violated," or a combination thereof. The severity of the violation may be weighted according to the magnitude of the violation, its duration, and the number of repetitions.

[0195] 6.21.3 Multi-source consistency and confidence fusion (example) In one embodiment, logical-side fields can come from multiple sources (OBD PID, raw CAN, GNSS, IMU, etc.), and the terminal can configure a confidence coefficient $w_s$ for each source. When a source's status is abnormal (SourceStatus is low confidence), its weight is reduced or it is excluded from the fusion.

[0196] In one embodiment, the fusion can be performed in the following non-limiting manner: 1) Weighted summation: $m_k=\sum_i w_i\cdot m_{k,i}$; 2) Voting strategy: A vote is passed if more than half of the sub-metrics pass; 3) Hierarchical strategy: First perform constraint consistency screening, then perform statistical correlation analysis; 4) Confidence interval strategy: Compare $m_k$ with the historical distribution and output a three-value judgment of strong pass / weak pass / rejection.

[0197] The selection and parameters of the above fusion method can be reflected by PolicyVer, which allows the server to explain "why the same raw data produces different decisions under different policies".

[0198] 6.22 Example parameter table, threshold meanings and interpretable definitions (further explanation) In one embodiment, a PolicySet may contain a set of interpretable parameters and reference its version identifier in auditing and documentation. The following are example parameters (not limiting): 1) ThrStrong: Strong pass threshold; if the threshold is met, a highly reliable credential is output. 2) ThrWeak: Weak pass threshold. If the threshold is met, output a low-credibility credential or mark it as weak pass. 3) ThrReject: Rejection threshold; if not met, the visa will be rejected and FR04 will be recorded. 4) MaxTimeSkew: The maximum allowed clock skew; exceeding this will trigger an audit / degradation process. 5) MaxCounterGap: The maximum allowed counter gap; exceeding this will trigger a retransmission or manual review. 6) NonceMode: Challenge binding mode (per window / by risk / by period); 7) AuditSignMode: Whether to generate anomaly audit credentials, and the range of fields covered by the signature.

[0199] In one embodiment, to facilitate understanding of the threshold meaning by different departments (risk control, dispute review, compliance), the server can map the key parameters in the PolicySet to "trust level" output instead of just outputting the numerical threshold, thereby reducing the interpretation cost.

[0200] 6.23 Boundary Conditions, False Rejection Suppression, and Degradation Paths (Further Explanation) In one embodiment, a short-term inconsistency may occur between the physical and logical sides of the terminal under the following boundary conditions: 1) Cold start transient: The voltage fluctuates drastically when the engine starts, and the logic-side fields may lag. 2) Rapid acceleration / braking: The logic side changes sharply, and there is a short-term deviation between the electrical load change and the sampling alignment; 3) Low battery / battery aging: Frequent undervoltage events cause abnormal physical characteristics, but the logic side may still be normal; 4) Bus congestion / packet loss: Missing logical-side fields render the decision unusable; 5) The vehicle is parked but the peripherals are working: for example, external electrical loads cause changes in voltage ripple characteristics.

[0201] To suppress erroneous rejections, in one embodiment, a degradation strategy may be adopted as follows: 1) If the logical side is missing but the physical side sampling is normal, then no business voucher will be generated; instead, an audit record will be generated and marked FR02. 2) If the time synchronization is unreliable, output a weak pass credential or only output a relative timeline, and mark the TimeState in DeviceStateRef; 3) If in a cold start transient, "relaxed threshold" or delayed decision can be enabled for the first few windows, and the start event flag can be recorded; 4) If the percentage of consecutive weak passes increases, it may trigger server-side policy feedback, increasing the challenge frequency or requiring additional fields.

[0202] By clearly defining the downgrade path and reason code, the server can distinguish between "short-term undeterminability caused by the environment" and "inconsistency caused by obvious adversarial behavior," thereby controlling the false rejection rate while ensuring adversarial capabilities.

[0203] 6.24 Privacy Minimization, Anonymized References, and Compliance Audit Support (Further Explanation) In one embodiment, to reduce privacy risks and data compliance pressures, the terminal can adopt a "reference-based and minimization" strategy in data blocks and credentials: 1) VehicleRef can be a summary or token of the vehicle identifier, rather than the plaintext VIN; 2) Logical fields can be selected based on the minimum necessary set, for example, only fields required for risk control or dispute review can be retained; 3) Physical side features can be reported based on statistical features rather than raw waveforms; 4) Set up desensitization and access control policies for fields that may contain personal information, and record access event summaries in the audit log.

[0204] In one embodiment, the server can separate "evidence storage" from "business use": evidence storage only saves the summary, credentials, and necessary reference fields; business use only accesses supplementary fields under authorized conditions. This separation helps demonstrate the "minimum principle" and "traceable access control" in compliance audits.

[0205] 6.25 Project Deployment, Version Compatibility, and Rollback Control (Further Explanation) In one embodiment, the terminal firmware and PolicySet are versioned, and the server selects the interpretation caliber according to the version.

[0206] Version 6.25.1 Compatibility (Example) Terminals can simultaneously carry the following in their credentials or data blocks: firmware version, PolicyVer, SpecVer, and ParseVer. When the server detects version incompatibility (e.g., SpecVer is not supported), it can refuse to add the data to the database or mark it as low trust, and issue a policy update command.

[0207] 6.25.2 Rollback Control (Example) To mitigate the risk of attackers rolling back to weakly gated firmware, in one embodiment, the terminal may enable Secure Boot or a firmware version rollback prevention mechanism and write a firmware version summary to the audit log. The server may issue alerts for "firmware version rollback events" and force an increase in the challenge frequency or suspend business credential generation.

[0208] Through the above deployment and compatibility control, interpretability and policy consistency can be maintained in the operation of large-scale device groups, and the difficulty of review caused by version drift can be reduced.

[0209] 6.26 Summary Normalization, Field Sorting, and Recalculation Guarantee (Further Explanation) In one embodiment, to ensure that the server or a third-party review agency can recalculate a consistent digest from the field set of the same window, this invention emphasizes "standardized coding caliber" in the digest construction.

[0210] 6.26.1 Field sorting rules (example) The terminal may use the following unrestricted rules to sort fields: 1) First, group by field type (identity type, window type, counter type, physical side type, logical side type, decision reference type, strategy / version type); 2) Sort within the group by field number or lexicographical order; 3) Explicitly specify the position or length field for optional fields to avoid different implementations from concatenating the same set of fields due to "missing fields".

[0211] In one embodiment, the terminal uses the version identifier of the collation rule as part of SpecVer, enabling the server to select the correct field sorting and encoding strategy based on SpecVer when recalculating the digest.

[0212] 6.26.2 Numerical Normalization and Unit Consistency (Example) For numerical fields (such as vehicle speed, rotational speed, and voltage characteristics), the terminal can adopt a normalization strategy of "fixed unit + fixed precision + range clipping": 1) Fixed units: For example, vehicle speed is uniformly measured in km / h, and engine speed is uniformly measured in rpm; 2) Fixed precision: For example, retaining a precision of 0.1 units or integerization; 3) Range clipping: Clip or mark values ​​that exceed the physical reasonable range as exceptions and write them to SourceStatus or FailReason.

[0213] The above normalization can reduce the problem of unreproducible summaries caused by differences in floating-point representation, unit differences, or outliers.

[0214] 6.27 Initialization Phase, Cold Start Learning, and Anti-Pollution Mechanism (Further Explanation) In one embodiment, the terminal may lack sufficient historical data to stably generate dynamic thresholds or vehicle profiles when it is first installed or powered on for the first time, thus requiring an initialization phase strategy.

[0215] 6.27.1 Cold Start Strategy (Example) During the cold start phase, conservative thresholds and low-risk strategies can be adopted: 1) Initially, only output weak pass certificates or only output audit records. Once enough pass windows have been accumulated, then enable strong pass. 2) Increase the frequency of random challenge number generation during the cold start phase to reduce the risk of contamination during replay; 3) Those with missing key fields or unusual sources are more sensitive and should be prioritized for auditing.

[0216] 6.27.2 Anti-pollution mechanisms (example) To prevent attackers from influencing dynamic thresholds or vehicle profiles through short-term forged windows, the terminal can employ the following non-restrictive anti-pollution mechanisms: 1) Update the profile only when the traffic is continuous and the source status is stable; 2) Set a maximum increment limit for image updates to prevent image drift caused by short-term anomalies; 3) Freeze profile updates when abnormal frequency increases or high-risk cause codes such as FR07 / FR06 appear; 4) Write freeze, rollback, and recovery events to the audit log so that the server can interpret them.

[0217] 6.28 Fault Recovery, Audit Preservation, and End-Side Evidence Export (Further Explanation) In one embodiment, the terminal needs to preserve the audit link as much as possible under fault conditions such as power failure, restart, and storage damage in order to avoid the loss of key evidence.

[0218] 6.28.1 Fault Recovery (Example) The terminal can perform the following recovery procedure at startup: 1) Check if the counter and the nearest window indicator are consecutive; 2) Check if the chained summaries of audit records are verifiable (if chained summaries are enabled). 3) If an anomaly is detected (e.g., chain break, counter rollback, timestamp anomaly), an audit start event is generated and the cause code FR06 / FR03 is marked. 4) When the network is restored, prioritize reporting the summary of the audit event and the abnormal audit credentials (if enabled).

[0219] 6.28.2 Evidence Export and Review Interface (Example) In one embodiment, the terminal supports exporting an "evidence package" within a specified window range under authorized conditions. The evidence package may include: 1) Summary and status verification credentials within this scope; 2) Corresponding abnormal audit records and abnormal audit vouchers; 3) PolicyVer / SpecVer / KeyVer and necessary version information; 4) Optional supplementary fields (access controlled).

[0220] The evidence package can be used for third-party review, dispute arbitration, or compliance inspection. Through the evidence package, the reviewing party can independently verify signatures, check the monotonicity of counters, and verify the one-time constraint of challenge random numbers, thereby forming a repeatable review conclusion.

[0221] 6.29 Verifiable Examples: Window Records, Voucher Chains, and Server Verification Output (Further Explanation) In one embodiment, to facilitate understanding of the end-to-cloud collaborative effect of "gated signature + audit closed loop", a verifiable, non-limiting example is given below.

[0222] 6.29.1 Window Recording Example Suppose that the terminal forms consecutive windows $W_k, W_{k+1}, W_{k+2}$ within a time period, with WindowIDs of $wid_k, wid_{k+1}, wid_{k+2}$ and monotonic counters of $ctr_k, ctr_{k+1}, ctr_{k+2}$.

[0223] 1) For $W_k$: When the consistency metric between the physical side and the logical side reaches the strong pass threshold, the terminal generates a state verification credential $v_k$, which references $wid_k$ and $ctr_k$ and contains PolicyVer and SpecVer; 2) For $W_{k+1}$: Packet loss from the logical side causes key fields to be missing. The terminal refuses to generate business vouchers and instead generates an abnormal audit record $a_{k+1}$ and marks it as FR02. At the same time, it is optional to generate an abnormal audit voucher $av_{k+1}$ for the audit summary. 3) For $W_{k+2}$: The server issues a challenge random number Nonce. After the terminal binds the NonceRef, it generates a state verification credential $v_{k+2}$. The server can verify the one-time constraint of the Nonce and mark the window as a higher trust level.

[0224] In one embodiment, if $W_{k+1}$ is in a cold start or time synchronization instability phase, the terminal can mark it as a weak pass or audit event, enabling the server to clearly distinguish between "data missing leading to indeterminacy" and "adversarial behavior leading to rejection".

[0225] 6.29.2 Server Review Output Example (Example) After the server reviews the above window, it can output the following structured conclusion (example): 1) Token chain conclusion: $v_k$ and $v_{k+2}$ have passed signature verification, and KeyVer is in the valid list; 2) Counter conclusion: $ctr_k \rightarrow ctr_{k+1} \rightarrow ctr_{k+2}$ is monotonically continuous, with no backtracking or repetition; 3) Policy consistency conclusion: PolicyVer / SpecVer is within the allowable range, and there are no rollback events; 4) Anomaly Explanation Conclusion: $W_{k+1}$ is an audit event caused by FR02 (logical side missing), and the audit summary can be verified (if $av_{k+1}$ exists); 5) Challenge the consistency conclusion: The NonceRef bound to $W_{k+2}$ is valid and not reused.

[0226] Through the above-mentioned review output, the server can not only determine "which windows' data can be used as credible evidence", but also provide explanations for "why certain windows cannot be used as highly credible evidence", and can associate and save the explanations with verifiable audit evidence for easy handling of subsequent disputes.

[0227] 6.30 Trust Level Output, Service Usage Isolation, and Closed-Loop Consistency (Further Explanation) In one embodiment, to facilitate direct use by business systems and reduce the risk of misuse, the server can map gating decisions and signature verification results to discrete trust level outputs. For example, the following non-restrictive levels can be output: 1) Level-A (High Trust): Strong pass and challenge verification passed (if enabled), continuous counter, and consistent version; 2) Level-B (Medium Trust): Weak pass or unbound challenge but satisfies gating and counter monotonicity; 3) Level-C (Low Trust): Explainable anomalies occur (e.g., FR02, TimeSkew is too large), but the audit log is complete; 4) Level-D (Unavailable): High-risk anomalies such as signature verification failure, counter rollback, and challenge duplication.

[0228] In one embodiment, the server routes data with different trust levels to different business channels: 1) Level-A / Level-B should be prioritized for risk control modeling channels; 2) The dispute review channel can use both Level-A / Level-B and Level-C audit evidence to explain the source of anomalies; 3) The compliance retention channel stores summaries, vouchers, and audit summaries to meet the principle of minimization and retain a verifiable link.

[0229] In one embodiment, to ensure closed-loop consistency, the server associates and stores "input reference fields, PolicyVer / SpecVer / KeyVer, signature verification result, counter verification result, challenge verification result, and trust level output" for each EvidenceRecord. This allows any subsequent review request to reproduce the original judgment logic and conclusion based on the same record. By incorporating key versions and reference fields of the judgment logic into the evidence storage, this invention maintains the interpretability and traceability of the evidence chain even with policy iterations and changes in device lifecycle.

[0230] 6.31 Anomaly Audit Document Coverage Fields, Replay Protection, and Hardware Binding (Further Explanation) In one embodiment, to ensure that refusal to sign and abnormal events have the same evidentiary attributes of being verifiable, traceable, and reviewable, the abnormal audit voucher can sign the audit summary and make a unified agreement on the fields covered by the audit summary.

[0231] 6.31.1 Audit Summary Coverage Fields (Example) An audit summary may cover at least the following set of fields: 1) FailReason (failure reason code and subcode); 2) WindowIDRef and CounterRef (window and counter references); 3) PolicyVer / SpecVer (Policy and Specification Versions); 4) MetricRef (the metric or its summary, threshold version identifier); 5) NonceRef (if challenges are enabled); 6) DeviceStateRef (a summary of interpretable fields such as time synchronization status and firmware version).

[0232] By covering the above fields, audit credentials not only prove that "an anomaly occurred," but also that "the anomaly is related to which window, which counter, which strategy, and which time synchronization state," thereby reducing the interpretation gap during dispute resolution.

[0233] 6.31.2 Audit-related replay protection (example) In one embodiment, audit credentials are also vulnerable to replay attacks (e.g., an attacker repeatedly submitting the same audit credential to create unusual noise). Therefore, the server can perform the following actions on the audit credential: 1) Deduplication based on WindowIDRef and CounterRef; 2) Time consistency verification based on AuditTS; 3) If challenges are enabled, a one-time constraint check is performed on NonceRef.

[0234] 6.31.3 Optional Enhancements to Hardware Binding (Example) In one embodiment, the terminal can incorporate hardware binding information, such as a device serial number digest, manufacturing batch digest, or trusted measurement value digest (ManufacturingRef / MeasurementRef), into the credential or audit log. This associates the credential not only with the key version but also with a specific hardware entity. This optional enhancement further reduces the risks associated with key duplication or cross-device forgery and improves the chain of evidence's focus on the "device entity."

[0235] In one embodiment, when the server detects that the same KeyVer appears on different TerminalIDs or that there is unreasonable geographical / temporal concurrency within the same time period, the server can classify the event as a high-risk anomaly and locate the source of the anomaly by combining the above-mentioned hardware binding summary; at the same time, it can trigger revocation or usage restriction policies and require the terminal to prioritize reporting audit-related credentials to preserve investigation evidence.

[0236] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit them. Various modifications, equivalent substitutions, and improvements made by those skilled in the art to the embodiments of the present invention without departing from the spirit and scope of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for generating reliable vehicle-mounted data, characterized in that, Performed by an onboard terminal comprising a voltage sampling circuit, a vehicle bus interface, and a security component for providing a protected key, the security component including a secure element or a trusted execution environment, the method includes: The system acquires a power supply voltage sequence and generates at least one physical side feature; acquires at least one logical side feature related to the vehicle's operating state; performs time alignment on the physical side feature and the logical side feature within a preset time window, and calculates a consistency metric to obtain a consistency decision result; performs normalized encoding on the data block to be reported, and generates a data block digest based on the normalized encoding result, wherein the data block digest is bound to at least the window identifier of the time window, the monotonic counter reference information, and the metric rule version identifier; when the consistency decision result meets a preset condition, the security component is triggered to perform an integrity protection operation on the data block digest, wherein the integrity protection... The operation includes digital signature or message authentication code to generate a status verification credential, and associates the status verification credential with the data block to be reported. When the consistency judgment result does not meet the preset conditions, the signature of the data block digest is refused and an abnormal audit record is generated. The security component is triggered to perform integrity protection operation on the audit digest of the abnormal audit record to generate an abnormal audit credential. The abnormal audit credential includes at least a failure reason code, the window identifier, the monotonic counter reference information, and the metric rule version identifier reference information. An idempotent key EvidenceId is generated for the status verification credential or the abnormal audit credential and reported to the server. The server deduplicates the EvidenceId and returns an idempotent receipt. The idempotent receipt includes at least OK or OK_DUP, and returns REJECT when the signature verification or format is invalid, and optionally carries a rejection reason code RejectReason. The security component enforces usage restrictions based on the usage identifier or authorization status: the generation of the status verification credential is prohibited while the generation of the abnormal audit credential is allowed in the key revocation or risk disposal status.

2. A vehicle-mounted data reliability generation device, comprising a voltage sampling circuit, a vehicle bus interface, a security unit, a processor, and a memory, characterized in that, The processor is configured to perform 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 physical side characteristics include at least one of ripple amplitude, peak frequency, harmonic structure, and energy bandwidth.

5. The method according to claim 1, wherein the logical side feature includes at least one of vehicle speed, rotational speed, and mileage increment.

6. The method according to claim 1, wherein the consistency metric includes any one of a correlation metric, a mutual information metric, a time series similarity metric, a constrained consistency metric, or a predictive consistency metric; wherein, The prediction consistency metric includes generating predicted values ​​based on a lightweight digital twin model or prediction model executed within the security component, and obtaining a decision result based on the residual between the predicted value and the actual observed value and a threshold comparison; the prediction model adopts deterministic reasoning and fixed-point quantization input and output, and completes reasoning within a preset resource upper bound, and its model version identifier or parameter group reference information is verified or validated by the terminal before being enabled.

7. The method according to claim 1, wherein the abnormal audit record includes at least the consistency metric value, the version identifier of the preset condition, and the failure reason code, and optionally includes the prediction model version identifier, the feature set version identifier, and the reference information of the prediction residual.

8. The method according to claim 1, wherein when the consistency decision result does not meet the preset conditions, the vehicle terminal refuses to write the data block digest to the sign buffer sign_buf or refuses to call the signature interface of the security component; and the vehicle terminal triggers the security component to perform integrity protection operation on the digest of the abnormal audit record to generate an abnormal audit credential.

9. The method according to claim 1, wherein the monotonic counter is stored in the anti-rollback area or bound to the anti-rollback counter, for preventing the repeated window or replay data block from generating new status verification credentials.

10. The method according to claim 1, wherein the vehicle terminal receives a challenge random number from a remote server and binds the challenge random number to the data block digest, and the status verification credential includes an integrity protection result, a timestamp, the window identifier, reference information of the challenge random number, and reference information of the consistency decision result; and when communication is unavailable, the status verification credential is offline sealed and resent upon communication recovery, and the server returns an idempotent receipt for duplicate status verification credentials. In a dispute-triggered review scenario, the remote server sends an audit request to the vehicle terminal. The audit request includes at least one of the following: an auth_token, a controlled disclosure field mask, a challenge_nonce, and a proof_type. The vehicle terminal outputs and reports the controlled disclosure review materials associated with the EvidenceId based on the audit request.

Images