Hardware detection method, system, vehicle and storage medium

Abstract

The application discloses a hardware detection method, system, vehicle and storage medium. The hardware detection method comprises the following steps: restoring a hardware fingerprint through a PUF; verifying a firmware signature, outputting a cryptography authentication result; performing challenge-response verification, outputting a hardware fingerprint verification result; calculating the Mahalanobis distance of a behavior feature and a behavior baseline, outputting a behavior baseline Mahalanobis distance; performing weighted fusion calculation on the cryptography authentication result, the hardware fingerprint verification result and the behavior baseline Mahalanobis distance to obtain a fusion decision score; and triggering an alarm when the fusion decision score falls within a decision interval. The hardware verification system comprises: a hardware fingerprint module; a cryptography binding module; a periodic authentication module; a bus behavior baseline module; and a multi-dimensional fusion detection module. The vehicle is provided with the hardware verification system. The storage medium stores computer executable instructions for enabling a computer to execute the hardware detection method. The scheme can effectively prevent illegal replacement of hardware or illegal hacking of hackers to ensure the safety of the vehicle.

Description

Technical Field

[0001] This invention relates to the technical field of vehicle information security, specifically to hardware detection methods, systems, vehicles, and storage media. Background Technology

[0002] With the continuous evolution of automotive electronic and electrical architecture, modern vehicles now contain dozens or even hundreds of ECUs. These controllers are interconnected via vehicle buses such as CAN, LIN, and Ethernet, forming a complex distributed computing system. In scenarios involving after-sales maintenance, illegal modifications, or supply chain attacks, attackers may replace legitimate controllers in a vehicle with tampered components of the same or different models to achieve purposes such as mileage tampering, emissions data falsification, and bypassing safety features.

[0003] Currently, controller legitimacy verification mainly relies on the following types of schemes: First, identity verification based on ECU hardware serial number, which is compared by reading chip identifier through OBD interface; second, integrity verification based on software version and checksum, which is checked by gateway or host computer during ECU startup; and third, identity authentication based on PKI digital certificate, with some high-end models achieving mutual authentication between nodes under the SecOC framework.

[0004] The hardware serial number-based approach has obvious flaws: chip identifiers can be cloned using a programmer, and attackers can modify the serial number of an illegal device to a legitimate value; a single identifier cannot resist cloning attacks.

[0005] Software checksum-based solutions only verify firmware integrity and cannot detect whether the underlying hardware has been replaced. If an attacker flashes the original firmware completely onto the replacement device, this solution becomes completely ineffective.

[0006] Existing SecOC implementations primarily focus on message authentication, addressing message forgery and replay issues, but lack a persistent binding and verification mechanism for node hardware identity. After a node's initial network entry, continuous monitoring of its hardware identity is generally lacking in subsequent communications.

[0007] Furthermore, existing solutions are all static single-point detection, lacking the ability to make multi-dimensional integrated judgments on controller physical characteristics (such as PUF response and timing characteristics), communication behavior baseline and cryptographic credentials. When facing advanced substitution attacks, they have high false alarm rates and low detection rates, making it difficult to meet the compliance requirements for supply chain security. Summary of the Invention This invention aims to solve at least one of the technical problems existing in the prior art. To this end, this invention provides a hardware detection method, system, vehicle, and storage medium.

[0008] According to a first aspect of the present invention, a hardware detection method includes the following steps: Several sets of excitation sequences are sent to the target ECU, and the excitation-response sequence from the target ECU is received. A stable hardware fingerprint is then restored using a fuzzy extraction algorithm. Based on the restored hardware fingerprint, verify the firmware signature and output the cryptographic authentication result Score_crypto; Send a challenge sequence to the target ECU, receive a challenge-response sequence generated by the target ECU based on the hardware fingerprint, verify the correctness of the challenge-response sequence, and output the hardware fingerprint verification result Score_hw; Real-time acquisition of behavioral features within the window, calculation of Mahalanobis distance between the behavioral features and the behavioral baseline, and output of Mahalanobis distance Score_behavior; The cryptographic authentication result Score_crypto, the hardware fingerprint verification result Score_hw, and the behavioral baseline Mahalanobis distance Score_behavior are weighted and fused to obtain the fused decision score Score_total. An alarm is triggered when the fusion decision falls within the decision range.

[0009] The hardware detection method according to embodiments of the present invention has at least the following beneficial effects: The system enables continuous monitoring of the legality of controller hardware throughout the entire vehicle lifecycle. Its detection accuracy and anti-attack capabilities are significantly superior to existing single-dimensional solutions, effectively preventing unauthorized hardware replacement or hacker intrusion to ensure vehicle safety.

[0010] According to some embodiments of the present invention, the decision interval includes a mildly abnormal interval, a moderately abnormal interval, and a severely abnormal interval; If the fusion judgment falls within the slightly abnormal range, a slightly abnormal alarm is triggered, and operations such as logging and reporting to CSMS are performed. If the fusion judgment falls within the moderate abnormal range, a moderate abnormality alarm will be triggered, the functional permissions of the target ECU will be restricted, and a warning message will be sent to the driver. If the fusion judgment falls within the severe anomaly range, a severe anomaly alarm is triggered, the target ECU is isolated, it is denied participation in safety-related functions, and a mandatory report is submitted to CSMS.

[0011] According to some embodiments of the present invention, a first weight w1, a second weight w2, and a third weight w3 are provided; the sum of w1, w2, and w3 is equal to 1; The fusion decision score is calculated as Score_total = w1×Score_hw + w2×Score_crypto + w3×Score_behavior.

[0012] According to some embodiments of the present invention, the challenge sequence is generated by a pseudo-random number generation algorithm using a random seed, a timestamp, and an ECU identifier.

[0013] According to some embodiments of the present invention, the firmware signature is generated by signing the firmware hash value, the hardware fingerprint of the original ECU, and the type identifier using a private key; during signature verification, the hardware fingerprint of the target ECU and the current firmware characteristics are used in conjunction with the OEM's public key for signature verification.

[0014] According to some embodiments of the present invention, the behavioral baseline BL = {msg_freq, msg_interval_mean, msg_interval_std, payload_dist, dlc_pattern}; Where msg_freq is the message sending frequency (messages / second); msg_interval_mean is the mean message interval (ms); msg_interval_std is the standard deviation of the message interval (ms); payload_dist is the histogram of data field byte distribution; dlc_pattern is the data length code distribution; The Mahalanobis distance of the behavioral baseline is Score_behavior = (BL_rt - BL_mean)^T × Σ^(-1) ×(BL_rt - BL_mean); Where BL_mean is the baseline mean vector, Σ is the baseline covariance matrix, and BL_rt is the real-time behavior feature vector.

[0015] According to a second aspect of the present invention, a hardware verification system operating at a central gateway includes: The hardware fingerprint module is used to extract the PUF fingerprint from the target ECU and output the hardware fingerprint. The cryptographic binding module is used to perform firmware-hardware binding on the hardware fingerprint and generate a firmware signature; and to verify the firmware signature on the hardware fingerprint of the target ECU and output the cryptographic authentication result. The periodic authentication module is used to issue challenge-response authentication to the target ECU at specific intervals and output the hardware fingerprint verification result; The bus behavior baseline module is used to collect bus communication behavior data of the target ECU and construct a behavior baseline; and to collect behavior features within the acquisition window, compare the behavior features with the behavior baseline, and output the Mahalanobis distance of the behavior baseline. The multidimensional fusion detection module has a built-in decision interval, which is used to calculate the fusion decision score by weighting the hardware fingerprint verification result, cryptographic authentication result, and behavioral baseline Mahalanobis distance. Then, the fusion decision score is compared with the decision interval to output an alarm response.

[0016] The hardware detection method according to embodiments of the present invention has at least the following beneficial effects: Through multiple detection modules, the legality of controller hardware can be continuously monitored throughout the vehicle's entire lifecycle. The detection accuracy and anti-attack capabilities are significantly better than existing single-dimensional solutions, effectively preventing unauthorized hardware replacement or hacker intrusion to ensure vehicle safety.

[0017] According to some embodiments of the present invention, the periodic authentication module is implemented based on the SecOC extended authentication protocol.

[0018] According to a third aspect of the present invention, a vehicle is equipped with the hardware verification system described in any of the preceding claims.

[0019] The hardware detection method according to embodiments of the present invention has at least the following beneficial effects: the vehicle information security of vehicles equipped with hardware verification systems is greatly improved.

[0020] According to a fourth aspect of the present invention, a computer-readable storage medium stores computer-executable instructions for causing a computer to perform any of the hardware detection methods described above.

[0021] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. Attached Figure Description

[0022] The present invention will be further described below with reference to the accompanying drawings and embodiments, wherein: Figure 1 This is a flowchart illustrating the hardware detection method according to an embodiment of the present invention. Figure 2 This is a schematic diagram illustrating alarm operations at different severity levels according to an embodiment of the present invention. Detailed Implementation

[0023] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0024] In the description of this invention, it should be understood that the orientation descriptions, such as up, down, etc., are based on the orientation or positional relationship shown in the drawings and are only for the convenience of describing this invention and simplifying the description, and are not intended to indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

[0025] In the description of this invention, "multiple" refers to two or more. The use of "first" and "second" is for distinguishing technical features only and should not be construed as indicating or implying relative importance, or implicitly indicating the number of indicated technical features or their sequential relationship.

[0026] In the description of this invention, unless otherwise explicitly defined, terms such as "setting," "installing," and "connecting" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this invention in conjunction with the specific content of the technical solution.

[0027] The technical solution of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are some embodiments of the present invention, not all embodiments.

[0028] The hardware testing method includes the following steps: S100: Send several sets of excitation sequences to the target ECU, receive the excitation-response sequence from the target ECU, and restore a stable hardware fingerprint through a fuzzy extraction algorithm; S200 verifies the firmware signature based on the restored hardware fingerprint and outputs the cryptographic authentication result Score_crypto. S300: Send a challenge sequence to the target ECU, receive a challenge-response sequence generated by the target ECU based on the hardware fingerprint, verify the correctness of the challenge-response sequence, and output the hardware fingerprint verification result Score_hw; S400: Real-time acquisition of behavioral features within the window, calculation of Mahalanobis distance between behavioral features and behavioral baseline, and output of Mahalanobis distance Score_behavior; S500: The cryptographic authentication result Score_crypto, the hardware fingerprint verification result Score_hw, and the behavioral baseline Mahalanobis distance Score_behavior are weighted and fused to obtain the fused decision score Score_total; S600. An alarm is triggered when the fusion decision falls within the decision interval. The decision interval is divided into a mild anomaly interval, a moderate anomaly interval, and a severe anomaly interval.

[0029] The S600 includes: S610. If the fusion decision falls within the slightly abnormal range, a slightly abnormal alarm is triggered, and operations such as logging and reporting to CSMS are performed. S620. If the fusion judgment falls within the moderate abnormal range, a moderate abnormality alarm is triggered, the functional permissions of the target ECU are restricted, and a warning message is sent to the driver. S630: If the fusion judgment falls within the severe anomaly range, a severe anomaly alarm is triggered, the target ECU is isolated, its participation in safety-related functions is denied, and a mandatory report is submitted to CSMS.

[0030] The system of this invention consists of the following functional modules: a hardware fingerprint acquisition module, a cryptographic binding module, a periodic authentication module, a bus behavior baseline module, and a multi-dimensional fusion detection module. This verification system runs on the vehicle central gateway (CGW) and performs continuous hardware legitimacy verification on all ECU nodes in the vehicle.

[0031] The hardware fingerprint acquisition module is used to extract the PUF fingerprint from the target ECU and output the hardware fingerprint.

[0032] During the ECU initialization phase, the gateway sends N sets of random stimulus sequences C = {c1, c2, ..., cN} to the target ECU. The ECU uses its built-in SRAM PUF or Ring Oscillator PUF to generate the corresponding response R = {r1, r2, ..., rN}, where ri = PUF(ci). Since the PUF response is determined by the chip's physical characteristics, the same stimulus produces different responses on different chips, and the response cannot be predicted through reverse engineering.

[0033] (FP, P) = Gen(R); FP: Hardware fingerprint, length k bits (usually k=128 or 256); P: Auxiliary data used for error correction in fuzzy extraction; R: Raw PUF response; The hardware fingerprint acquisition module performs fuzzy extraction on the raw PUF response to generate a stable k-bit hardware fingerprint FP, and outputs auxiliary data P for subsequent reconstruction. FP' = Rep(R', P); Gen(): The generation function, used during the initial data collection; Rep(): The reconstruction function, used for subsequent verification; R': Noisy PUF response; While extracting the fingerprint, the chip serial number UID, clock frequency deviation Δf, and startup timing feature vector T of the ECU are collected. Together with the PUF fingerprint, they form a multi-dimensional hardware feature vector: HF = [FP, UID, Δf, T].

[0034] The cryptographic binding module is used to implement fingerprint registration, firmware-hardware binding, verify the hardware fingerprint of the target ECU, and finally output the cryptographic authentication result Score_crypto (0=pass, 1=fail).

[0035] Fingerprint registration is performed in a trusted environment when the vehicle leaves the factory or the ECU is first connected to the network, completing hardware fingerprint registration and generating binding credentials. CERT_HW = Sign_SK_OEM(UID || FP || ECU_Type || VIN || Timestamp); CERT_HW: Hardware binding certificate; Sign_SK_OEM(): OEM private key signing function; UID: Unique Identifier for Chip; FP: PUF hardware fingerprint; ECU_Type: Controller type identifier; VIN: Vehicle Identification Number; Timestamp: Registration timestamp to prevent replay; Firmware-hardware binding introduces hardware fingerprint binding on top of traditional code integrity for firmware signing: SIG_FW = Sign_SK_OEM(Hash(Firmware) || FP || ECU_Type) This binds the firmware signature to a specific hardware instance. The replaced device causes the firmware signature verification to fail due to FP mismatch.

[0036] The SecOC extended authentication module extends the dynamic binding mechanism of node hardware identity based on the AUTOSAR SecOC standard framework: the dynamic binding mechanism includes periodic challenge-response authentication and MAC extension.

[0037] Periodic challenge - Response authentication is a hardware identity challenge initiated by the gateway to each ECU node at a period of T_auth (configurable, default 30 minutes): Challenge = PRNG(Seed_GW || Timestamp || ECU_ID); Response = HMAC_SHA256(FP || UID, Challenge); Challenge: Random challenge value to prevent replay attacks; PRNG(): Pseudo-random number generation function; Seed_GW: Random seed on the gateway side; ECU_ID: Identifier of the target ECU; Response: The response value calculated by the ECU based on the hardware fingerprint; HMAC_SHA256(): Message authentication code function based on SHA-256; FP: ECU hardware fingerprint, used as HMAC key material; The MAC extension introduces a hardware fingerprint digest, HF_digest, into the MAC calculation of the SecOC frame. MAC_Extended = CMAC(SessionKey || HF_digest, Payload); HF_digest = SHA256(FP)[0:32] (take the first 32 bits as the digest); SessionKey: Session key, derived from challenge-response negotiation; HF_digest: Hardware fingerprint digest; Payload: Raw message data; CMAC(): AES-based message authentication code.

[0038] The bus behavior baseline module includes steps such as baseline establishment and anomaly scoring, and outputs Score_behavior: Mahalanobis distance of the behavior baseline (normalized to [0,1]).

[0039] The baseline is established by collecting bus communication behavior data of each ECU under normal operating conditions after the vehicle leaves the factory, and extracting statistical features to construct the behavioral baseline: BL = {msg_freq, msg_interval_mean, msg_interval_std, payload_dist,dlc_pattern}; msg_freq: Message sending frequency (messages / second); msg_interval_mean: The average message interval (ms); msg_interval_std: Standard deviation of message interval (ms); payload_dist: Histogram of data field byte distribution; dlc_pattern: Data length code distribution; Anomaly scoring is based on behavioral characteristics within a real-time acquisition window W. Calculate Mahalanobis distance as a behavioral anomaly score: Score_behavior =(BL_rt - BL_mean)^T × Σ^(-1) × (BL_rt - BL_mean); BL_mean: Baseline mean vector; Σ: Baseline covariance matrix; BL_rt: Real-time behavior feature vector.

[0040] The multi-dimensional fusion detection module is used to calculate the three-dimensional anomaly score.

[0041] Score_hw: Hardware fingerprint verification result (0 = passed, 1 = failed); Fusion decision: The weighted fusion strategy is adopted to calculate the comprehensive anomaly score: Score_total = w1×Score_hw + w2×Score_crypto + w3×Score_behavior w1, w2, w3: Weights of each dimension (w1+w2+w3 = 1, default w1 = 0.45, w2 = 0.40, w3 = 0.15) When Score_total falls into the decision interval, it is determined as a controller replacement event and an alarm is triggered.

[0042] Alarm response: After detecting the replacement event, the system executes a hierarchical response strategy: Minor anomaly (0.5 < Score_total ≤ 0.7): Record the log, report to CSMS, and do not affect the vehicle function; Moderate anomaly (0.7 < Score_total ≤ 0.9): Restrict the function permission of the target ECU and give a driver prompt; Severe anomaly (Score_total > 0.9): Isolate the abnormal node, reject its participation in safety-related functions, and force reporting.

[0043] Example 1: ECU hardware replacement detection Application scenario: The engine ECU (EMS) of a mass-produced vehicle model is illegally replaced by a clone device of the same model in an illegal after-sales channel. The clone device is flashed with the same firmware as the original ECU, but the physical characteristics of the chip are different from the original.

[0044] Detection process: The gateway initiates a PUF excitation to the EMS within 5 seconds after the vehicle is powered on and sends 64 groups of random challenge sequences. Due to physical differences, the SRAM PUF response of the cloned chip is inconsistent with the registered value. The Hamming distance between the reconstituted FP' and the original FP after fuzzy extraction exceeds the threshold (HD > 8 bits), and the hardware fingerprint verification fails, Score_hw = 1.

[0045] In the firmware signature verification stage, due to the inconsistency between the FP in the bound certificate and the actual FP of the cloned chip, the digital signature verification fails, Score_crypto = 1.

[0046] The cloned device exhibits a slight deviation in message transmission timing from the baseline under specific operating conditions (caused by clock frequency differences), resulting in an abnormal behavior score of Score_behavior=0.3.

[0047] The combined calculation shows that Score_total = 0.45×1 + 0.40×1 + 0.15×0.3 = 0.895, which falls within the judgment range of moderate anomaly, triggering a moderate alarm. EMS is then restricted in its functions and reported to CSMS.

[0048] Example 2: Gateway Replacement Detection Application scenario: In supply chain attacks, the CGW gateway is replaced with a device that looks the same but has had its firmware tampered with. The attacker retains the original gateway's UID and attempts to forge a PUF response.

[0049] Detection Process: Due to the unpredictability of PUF responses, attackers cannot generate the correct PUF response sequence without possessing the original chip. A periodic challenge occurs when response authentication fails, and the gateway itself experiences an anomaly in SecOC key negotiation, resulting in a total score of 0.97, triggering a critical alarm. The entire vehicle enters a secure mode, refusing to execute remote commands and awaiting OEM authorization for further action.

[0050] Example 3: Whitelist update in compliant repair scenarios Application scenario: Car owners replace damaged BCM controllers at authorized 4S stores. The new device is legal but requires identity registration.

[0051] Process: The technician connects to the vehicle using an OEM-authorized diagnostic tool, which requests a temporary authorization token from the cloud-based CSMS. The CSMS verifies the VIN and repair work order and then issues the authorization. Within the validity period of the authorization token, the gateway completes PUF collection and certificate registration for the new BCM. After registration, the new BCM is added to the list of legitimate nodes, and subsequent tests pass normally.

[0052] This invention also provides a vehicle equipped with the aforementioned hardware detection system. Specifically, the vehicle can be a private car, such as a sedan, SUV, MPV, or pickup truck. The vehicle can also be a commercial vehicle, such as a van, bus, small truck, or large semi-trailer. The vehicle can be a gasoline-powered vehicle or a new energy vehicle. When the vehicle is a new energy vehicle, it can be a hybrid vehicle or a pure electric vehicle.

[0053] The computer-readable storage medium of this invention can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0054] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0055] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0056] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system.

[0057] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0058] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings. However, the present invention is not limited to the above embodiments. Within the scope of knowledge possessed by those skilled in the art, various changes can be made without departing from the spirit of the present invention.

Claims

1. Hardware testing method, including the following steps: Several sets of excitation sequences are sent to the target ECU, and the excitation-response sequence from the target ECU is received. A stable hardware fingerprint is then restored using a fuzzy extraction algorithm. Based on the restored hardware fingerprint, verify the firmware signature and output the cryptographic authentication result Score_crypto; Send a challenge sequence to the target ECU, receive a challenge-response sequence generated by the target ECU based on the hardware fingerprint, verify the correctness of the challenge-response sequence, and output the hardware fingerprint verification result Score_hw; Real-time acquisition of behavioral features within the window, calculation of Mahalanobis distance between the behavioral features and the behavioral baseline, and output of Mahalanobis distance Score_behavior; The cryptographic authentication result Score_crypto, the hardware fingerprint verification result Score_hw, and the behavioral baseline Mahalanobis distance Score_behavior are weighted and fused to obtain the fused decision score Score_total. An alarm is triggered when the fusion decision falls within the decision range.

2. The hardware testing method according to claim 1, characterized in that, The judgment interval is divided into mild abnormality interval, moderate abnormality interval, and severe abnormality interval; If the fusion judgment falls within the slightly abnormal range, a slightly abnormal alarm is triggered, and operations such as logging and reporting to CSMS are performed. If the fusion judgment falls within the moderate abnormal range, a moderate abnormality alarm will be triggered, the functional permissions of the target ECU will be restricted, and a warning message will be sent to the driver. If the fusion judgment falls within the severe anomaly range, a severe anomaly alarm is triggered, the target ECU is isolated, it is denied participation in safety-related functions, and a mandatory report is submitted to CSMS.

3. The hardware testing method according to claim 1, characterized in that, Let there be a first weight w1, a second weight w2, and a third weight w3; the sum of w1, w2, and w3 equals 1. The fusion decision score is calculated as Score_total = w1×Score_hw + w2×Score_crypto + w3×Score_behavior.

4. The hardware testing method according to claim 2, characterized in that, The challenge sequence is generated by a pseudo-random number generation algorithm using a random seed, timestamp, and ECU identifier.

5. The hardware testing method according to claim 1, characterized in that, Firmware signature is generated by signing the firmware hash value, the hardware fingerprint of the original ECU, and the type identifier using a private key; during signature verification, the hardware fingerprint of the target ECU and the current firmware characteristics are used in conjunction with the OEM's public key for signature verification.

6. The hardware testing method according to claim 1, characterized in that, Behavioral baseline BL = {msg_freq, msg_interval_mean, msg_interval_std, payload_dist, dlc_pattern}; Where msg_freq is the message sending frequency (messages / second); msg_interval_mean is the mean message interval (ms); msg_interval_std is the standard deviation of the message interval (ms); payload_dist is the histogram of data field byte distribution; dlc_pattern is the data length code distribution; The Mahalanobis distance of the behavioral baseline is Score_behavior = (BL_rt - BL_mean)^T × Σ^(-1) × (BL_rt - BL_mean); Where BL_mean is the baseline mean vector, Σ is the baseline covariance matrix, and BL_rt is the real-time behavior feature vector.

7. A hardware verification system, characterized in that, Running on the central gateway, including: The hardware fingerprint module is used to extract the PUF fingerprint from the target ECU and output the hardware fingerprint. The cryptographic binding module is used to perform firmware-hardware binding on the hardware fingerprint and generate a firmware signature; and to verify the firmware signature on the hardware fingerprint of the target ECU and output the cryptographic authentication result. The periodic authentication module is used to issue challenge-response authentication to the target ECU at specific intervals and output the hardware fingerprint verification result; The bus behavior baseline module is used to collect bus communication behavior data of the target ECU and construct a behavior baseline; and to collect behavior features within the acquisition window, compare the behavior features with the behavior baseline, and output the Mahalanobis distance of the behavior baseline. The multidimensional fusion detection module has a built-in decision interval, which is used to calculate the fusion decision score by weighting the hardware fingerprint verification result, cryptographic authentication result, and behavioral baseline Mahalanobis distance. Then, the fusion decision score is compared with the decision interval to output an alarm response.

8. The hardware verification system according to claim 1, characterized in that, The periodic authentication module is implemented based on the SecOC extended authentication protocol.

9. A vehicle, characterized in that, It is equipped with the hardware verification system as described in any one of claims 7-8.

10. A computer-readable storage medium, characterized in that, A computer-readable storage medium stores computer-executable instructions for causing a computer to perform the hardware detection method as described in any one of claims 1-6.

Images