Protection method, device and vehicle for hsm

Abstract

The embodiment of the application provides a protection method and device of an HSM and a vehicle, the method comprises the following steps: acquiring a real-time service request sequence about the HSM and real-time running information of the vehicle; performing inference processing on the real-time service request sequence and the real-time running information through an AI detection engine in the vehicle to obtain target safety evaluation data of the HSM, wherein the AI detection engine is deployed with a detection model trained based on multiple service request sequences, multiple running information and multiple labeled safety evaluation data; and performing protection processing on the HSM according to the target safety evaluation data. By applying the technical solution, the use safety of the HSM in the vehicle can be improved.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and more particularly to a method, device, and vehicle for protecting against HSM (Hardware Self-Protection). Background Technology

[0002] The Hardware Security Module (HSM), as the core security chip in the Electronic Control Unit (ECU) of an automobile, is responsible for key tasks such as storing the vehicle's digital certificate, executing secure communication protocols, and completing firmware signature verification for Over-The-Air (OTA) technology. It is the root of trust of the vehicle system.

[0003] With the increasing software-defined vehicle (SDV) and connectivity of vehicles, attackers, after gaining execution privileges on the system-on-chip (SoC), may use legitimate software interfaces to launch abnormal calls to the vehicle's HSM (Hardware Service Controller).

[0004] However, current in-vehicle systems lack the ability to detect online anomalies in HSM cryptographic interface calls. Attackers can abuse HSM services in a low-frequency manner for extended periods without triggering alarms, leading to serious security incidents such as key leaks and identity forgery. Summary of the Invention

[0005] This application provides a method, apparatus, and vehicle for protecting HSMs, thereby improving the technical effectiveness of HSM use safety in vehicles.

[0006] In a first aspect, embodiments of this application provide a method for protecting HSMs, comprising:

[0007] Obtain the real-time service request sequence for HSM in the vehicle and the real-time operating information of the vehicle;

[0008] The AI ​​detection engine in the vehicle performs inference processing on the real-time service request sequence and the real-time operation information to obtain the target security evaluation data of the HSM. The AI ​​detection engine is equipped with a detection model trained based on multiple service request sequences, multiple operation information, and multiple labeled security evaluation data.

[0009] Based on the target security evaluation data, the HSM is subjected to protective measures.

[0010] In one or more embodiments, the corresponding operational information includes: vehicle speed data and vehicle operating status; the vehicle operating status includes: driving status, parking status, and OTA upgrade status;

[0011] Accordingly, the detection model includes: a first model corresponding to the driving state, a second model corresponding to the parking state, and a third model corresponding to the OTA upgrade state;

[0012] The first model is obtained by training an LSTM based on multiple vehicle speed data, multiple service request sequences, and multiple labeled safety evaluation data under the driving state; the second model is obtained by training an LSTM based on multiple service request sequences and multiple labeled safety evaluation data under the parking state; and the third model is obtained by training an LSTM based on multiple vehicle speed data, multiple service request sequences, and multiple labeled safety evaluation data under the OTA upgrade state.

[0013] In one or more embodiments, the step of performing inference processing on the real-time service request sequence and the real-time operation information to obtain the target security evaluation data of the HSM includes:

[0014] Based on the vehicle operating status in the real-time operating information, a target model is determined in the detection model. The target model is any one of the first model, the second model, and the third model.

[0015] The real-time service request sequence and the vehicle speed data from the real-time operation information required under the target model are input into the target model to obtain the target safety evaluation data.

[0016] In one or more embodiments, the step of inputting the real-time service request sequence and vehicle speed data from the real-time operational information required under the target model into the target model to obtain the target safety evaluation data includes:

[0017] The target model determines a first score, a second score, and a third score based on the real-time service request sequence and the vehicle speed data in the real-time operation information required under the target model. The first score is the standardized deviation score of the request frequency, the second score is the sequence reconstruction loss score of LSTM, and the third score is the cumulative deviation score of the real-time service request sequence within multiple time windows.

[0018] The target security evaluation data is obtained by weighting and fusing the first score, the second score, and the third score using the target model.

[0019] In one or more embodiments, the step of performing protective processing on the HSM based on the target security evaluation data includes:

[0020] If the target security evaluation data is less than or equal to a first preset threshold, the HSM is subjected to a first protection process, which is to continuously monitor the HSM through the AI ​​detection engine.

[0021] If the target security evaluation data is greater than the first preset threshold and less than or equal to the second preset threshold, the HSM is subjected to a second protection process, which is to increase the sampling frequency of the AI ​​detection engine and record alarm logs.

[0022] If the target security evaluation data is greater than the second preset threshold and less than or equal to the third preset threshold, the HSM is subjected to a third protection process. The third protection process is to control the HSM to perform key rotation and, after rotation, control the AI ​​detection engine to send a recovery confirmation token to the HSM.

[0023] If the target security evaluation data is greater than the third preset threshold, the HSM will be subjected to a fourth protection process, which includes controlling the HSM to destroy the temporary session key and enter a complete isolation mode, and sending an emergency alarm.

[0024] In one or more embodiments, before the method performs inference processing on the real-time service request sequence and the real-time operational information through the AI ​​detection engine in the vehicle to obtain the target safety evaluation data of the HSM, the method further includes:

[0025] The HSM performs integrity verification on the model parameters of the detection model deployed in the AI ​​detection engine. The integrity verification includes: the HSM decrypts the pre-stored key ciphertext using its own private key to obtain a symmetric key, decrypts the pre-stored parameter ciphertext using the symmetric key to obtain plaintext parameters, calculates the first hash value of the plaintext parameters, and compares the first hash value with a pre-stored reference hash value.

[0026] After the integrity verification is passed, a temporary session key is generated through negotiation between the HSM and the AI ​​detection engine, and the model parameters are encrypted and transmitted to the AI ​​detection engine using the temporary session key.

[0027] In one or more embodiments, prior to performing integrity verification on the model parameters of the detection model deployed in the AI ​​detection engine via the HSM, the method further includes:

[0028] The ciphertext of the parameters, the ciphertext of the key, the reference hash value, and the CA signature of the vehicle manufacturer are obtained through the OTA security channel used by the vehicle for communication. The ciphertext of the parameters is obtained by encrypting the model parameters with a random symmetric key. The ciphertext of the key is obtained by encrypting the random symmetric key with the public key of the HSM. The CA signature of the vehicle manufacturer is used to verify the origin of the detection model when the vehicle is updated via OTA.

[0029] The parameter ciphertext, the key ciphertext, the reference hash value, and the vehicle manufacturer's CA signature are written into the secure storage area of ​​the HSM.

[0030] In one or more embodiments, the method further includes:

[0031] The AI ​​detection engine generates an evidence collection data package based on the target security evaluation data and the real-time operation information. The evidence collection data package includes: abnormal event type, timestamp, security evaluation data, vehicle identification code, and HSM identifier.

[0032] The evidence collection data packet is signed by the HSM and the signed evidence collection data packet is stored in non-volatile memory;

[0033] When the storage utilization rate of the non-volatile memory reaches a preset threshold, the signed evidence data packet is uploaded through the encrypted channel used for communication by the vehicle.

[0034] Secondly, embodiments of this application provide a protective device for HSMs, comprising:

[0035] The acquisition module is used to acquire the real-time service request sequence of HSM in the vehicle and the real-time operation information of the vehicle;

[0036] The first processing module is used to perform inference processing on the real-time service request sequence and the real-time operation information through the AI ​​detection engine in the vehicle to obtain the target security evaluation data of the HSM. The AI ​​detection engine is equipped with a detection model trained based on multiple service request sequences, multiple operation information, and multiple labeled security evaluation data.

[0037] The second processing module is used to perform protection processing on the HSM based on the target security evaluation data.

[0038] In one or more embodiments, the corresponding operational information includes: vehicle speed data and vehicle operating status; the vehicle operating status includes: driving status, parking status, and OTA upgrade status;

[0039] Accordingly, the detection model includes: a first model corresponding to the driving state, a second model corresponding to the parking state, and a third model corresponding to the OTA upgrade state;

[0040] The first model is obtained by training an LSTM based on multiple vehicle speed data, multiple service request sequences, and multiple labeled safety evaluation data under the driving state; the second model is obtained by training an LSTM based on multiple service request sequences and multiple labeled safety evaluation data under the parking state; and the third model is obtained by training an LSTM based on multiple vehicle speed data, multiple service request sequences, and multiple labeled safety evaluation data under the OTA upgrade state.

[0041] In one or more embodiments, the first processing module is specifically used for:

[0042] Based on the vehicle operating status in the real-time operating information, a target model is determined in the detection model. The target model is any one of the first model, the second model, and the third model.

[0043] The real-time service request sequence and the vehicle speed data from the real-time operation information required under the target model are input into the target model to obtain the target safety evaluation data.

[0044] In one or more embodiments, the first processing module inputs the real-time service request sequence and the vehicle speed data from the real-time operating information required under the target model into the target model to obtain the target safety evaluation data, specifically for:

[0045] The target model determines a first score, a second score, and a third score based on the real-time service request sequence and the vehicle speed data in the real-time operation information required under the target model. The first score is the standardized deviation score of the request frequency, the second score is the sequence reconstruction loss score of LSTM, and the third score is the cumulative deviation score of the real-time service request sequence within multiple time windows.

[0046] The target security evaluation data is obtained by weighting and fusing the first score, the second score, and the third score using the target model.

[0047] In one or more embodiments, the second processing module performs protection processing on the HSM based on the target security evaluation data, specifically for:

[0048] If the target security evaluation data is less than or equal to a first preset threshold, the HSM is subjected to a first protection process, which is to continuously monitor the HSM through the AI ​​detection engine.

[0049] If the target security evaluation data is greater than the first preset threshold and less than or equal to the second preset threshold, the HSM is subjected to a second protection process, which is to increase the sampling frequency of the AI ​​detection engine and record alarm logs.

[0050] If the target security evaluation data is greater than the second preset threshold and less than or equal to the third preset threshold, the HSM is subjected to a third protection process. The third protection process is to control the HSM to perform key rotation and, after rotation, control the AI ​​detection engine to send a recovery confirmation token to the HSM.

[0051] If the target security evaluation data is greater than the third preset threshold, the HSM will be subjected to a fourth protection process, which includes controlling the HSM to destroy the temporary session key and enter a complete isolation mode, and sending an emergency alarm.

[0052] In one or more embodiments, before the AI ​​detection engine in the vehicle performs inference processing on the real-time service request sequence and the real-time operation information to obtain the target safety evaluation data of the HSM, the first processing module is further configured to:

[0053] The HSM performs integrity verification on the model parameters of the detection model deployed in the AI ​​detection engine. The integrity verification includes: the HSM decrypts the pre-stored key ciphertext using its own private key to obtain a symmetric key, decrypts the pre-stored parameter ciphertext using the symmetric key to obtain plaintext parameters, calculates the first hash value of the plaintext parameters, and compares the first hash value with a pre-stored reference hash value.

[0054] After the integrity verification is passed, a temporary session key is generated through negotiation between the HSM and the AI ​​detection engine, and the model parameters are encrypted and transmitted to the AI ​​detection engine using the temporary session key.

[0055] In one or more embodiments, before performing integrity verification on the model parameters of the detection model deployed in the AI ​​detection engine via the HSM, the first processing module is further configured to:

[0056] The ciphertext of the parameters, the ciphertext of the key, the reference hash value, and the CA signature of the vehicle manufacturer are obtained through the OTA security channel used by the vehicle for communication. The ciphertext of the parameters is obtained by encrypting the model parameters with a random symmetric key. The ciphertext of the key is obtained by encrypting the random symmetric key with the public key of the HSM. The CA signature of the vehicle manufacturer is used to verify the origin of the detection model when the vehicle is updated via OTA.

[0057] The parameter ciphertext, the key ciphertext, the reference hash value, and the vehicle manufacturer's CA signature are written into the secure storage area of ​​the HSM.

[0058] In one or more embodiments, the first processing module is further configured to:

[0059] The AI ​​detection engine generates an evidence collection data package based on the target security evaluation data and the real-time operation information. The evidence collection data package includes: abnormal event type, timestamp, security evaluation data, vehicle identification code, and HSM identifier.

[0060] The evidence collection data packet is signed by the HSM and the signed evidence collection data packet is stored in non-volatile memory;

[0061] When the storage utilization rate of the non-volatile memory reaches a preset threshold, the signed evidence data packet is uploaded through the encrypted channel used for communication by the vehicle.

[0062] Thirdly, embodiments of this application provide a vehicle, including: a memory and a processor;

[0063] The memory stores computer-executed instructions;

[0064] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0065] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0066] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0067] The HSM protection method, device, and vehicle provided in this application embodiment acquire real-time service request sequences and real-time vehicle operation information from the vehicle; through an AI detection engine in the vehicle, the real-time service request sequences and real-time operation information are processed for inference to obtain target security evaluation data for the HSM. The AI ​​detection engine is equipped with a detection model trained based on multiple service request sequences, multiple operation information, and multiple labeled security evaluation data; and protection processing is performed on the HSM based on the target security evaluation data. This technical solution, by acquiring the real-time service request sequences and vehicle operation information of the HSM and using the pre-trained detection model in the AI ​​detection engine for comprehensive inference, can achieve efficient and dynamic security assessment of the HSM's operational status. Based on the obtained target security evaluation data, corresponding protection processing mechanisms can be automatically triggered, thereby timely identifying potential abnormal behaviors and executing targeted responses without interrupting normal business operations, effectively enhancing the HSM's anti-interference and anti-attack capabilities while reducing reliance on manual intervention. Attached Figure Description

[0068] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0069] Figure 1 Flowchart of the HSM protection method provided in the embodiments of this application Figure 1 ;

[0070] Figure 2 Flowchart of the HSM protection method provided in the embodiments of this application Figure 2 ;

[0071] Figure 3 Flowchart of the HSM protection method provided in the embodiments of this application Figure 3 ;

[0072] Figure 4 Flowchart of the HSM protection method provided in the embodiments of this application Figure 4 ;

[0073] Figure 5 Flowchart of the HSM protection method provided in the embodiments of this application Figure 5 ;

[0074] Figure 6 A schematic diagram of the protective device for HSM provided in the embodiments of this application;

[0075] Figure 7 This is a structural schematic diagram of the vehicle provided in an embodiment of this application.

[0076] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0077] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0078] In the field of intelligent connected vehicles, the HSM (Hardware Controller System) is the core security chip in the automotive electronic control unit responsible for key storage and cryptographic operations. It undertakes key tasks such as vehicle digital certificate management, secure communication, and OTA firmware signature verification, and serves as the root of trust for vehicle security.

[0079] As vehicles become increasingly software-defined and connected, attackers, after gaining execution privileges on the vehicle SoC, can launch abnormal calls to the HSM through legitimate software interfaces. These attacks can include high-frequency brute-force key enumeration operations, slow penetration attacks disguised as normal business processes, or tampering with AI detection model parameters to bypass security detection. These runtime behavior attacks do not change the HSM firmware itself and therefore cannot be detected by traditional static integrity verification mechanisms.

[0080] Currently, in-vehicle systems lack the ability to detect online anomalies in HSM cryptographic interface calls. Attackers can abuse HSM services at low frequency for extended periods without triggering any alarms, leading to serious security incidents such as key leakage and identity forgery.

[0081] Meanwhile, existing solutions typically only allow for manual intervention to recover after an HSM anomaly, lacking an automated closed-loop self-healing mechanism. Vehicles remain exposed to risk during the window between the attack and manual response.

[0082] The current approach to solving the above problems is as follows:

[0083] 1) Static integrity measurement: HSM firmware and configuration are hashed during the vehicle system startup phase to ensure that the HSM has not been tampered with during startup (e.g., a secure startup process that conforms to the EVITA FULL specification).

[0084] 2) Access Control and Permission Isolation: Hardware isolation and Access Control Lists (ACLs) are used to restrict which ECU modules can access which services of the HSM, preventing unauthorized access.

[0085] 3) Call frequency rate limiting: Set a fixed maximum call threshold per second in the HSM firmware. If the threshold is exceeded, the service will be denied to prevent brute-force enumeration attacks.

[0086] 4) Rule-based intrusion detection: Configure static rules in the intrusion detection system (IDS) to match and alert on abnormal patterns of specific HSM service requests (e.g., 10 consecutive Advanced Encryption Standard (AES) decryption requests from the same ECU).

[0087] 5) Post-event log auditing: Record HSM service call logs, which are then analyzed offline by the vehicle manufacturer's security team to check for any anomalies.

[0088] However, the above implementation presents the following technical problems:

[0089] 1) Static integrity metrics only cover the startup time and cannot detect runtime behavioral attacks.

[0090] Cause: After startup, abnormal calls initiated by attackers through legitimate software interfaces do not change the firmware content, static metrics remain valid, and the detection mechanism is ineffective.

[0091] 2) Fixed frequency rate limiting cannot cope with low-frequency, slow attacks.

[0092] Reason: Attackers keep the call frequency below the threshold and achieve key enumeration through long-term accumulation. The fixed threshold cannot distinguish between normal business fluctuations and slow attacks, resulting in high false positive and false negative rates.

[0093] 3) Static rules cannot adapt to the dynamic changes in vehicle driving status.

[0094] Reason: The HSM calling mode varies significantly under different driving states (driving / parking / OTA upgrade). Static rules are either too lenient, leading to missed detections, or too strict, leading to a large number of false alarms.

[0095] 4) Lacks automated closed-loop self-healing capabilities, and attack response relies on manual intervention.

[0096] Cause: There is no standardized state synchronization protocol between detection and response. HSM cannot automatically detect the detection results and trigger key rotation, nor can it automatically restore normal service after the response is completed, resulting in a long window period after the attack.

[0097] 5) The authenticity of the evidence data cannot be guaranteed.

[0098] Reason: Logs are stored on general-purpose storage media. After gaining SoC privileges, attackers can delete or modify log records, making subsequent tracing and judicial evidence collection impossible.

[0099] To address the technical problems existing in the prior art, the inventors of this application propose the following concept: As a core component of cryptographic operations, the operational security of the HSM directly affects the network security of the entire vehicle. However, current anomaly detection methods based on rules or thresholds are insufficient to handle behavioral deviations under complex dynamic vehicle conditions. Meanwhile, AI detection engines can learn normal behavior patterns from a large amount of time-series data and have the ability to identify weak or gradual anomalies. Based on this understanding, if service request sequences (e.g., request type, source domain ID, timestamp) generated by the HSM during actual operation, as well as vehicle status information such as vehicle speed and operating mode, are collected, and the AI ​​detection engine is used to fuse and infer these multi-source time-series data, a pre-trained detection model can be pre-deployed and used as an inference model for security evaluation data during actual use. Finally, based on the security evaluation data, specific protection operations can be performed, such as driving the HSM to perform key rotation, restricted mode switching, or graded protection measures such as evidence reporting. This would enable proactive perception and closed-loop management of the HSM's operational security status.

[0100] The technical solution of this application and how it solves the above-mentioned technical problems will be described in detail below with specific embodiments. The subject of this technical solution is a vehicle, such as a control unit in a vehicle.

[0101] The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0102] Figure 1 Flowchart of the HSM protection method provided in the embodiments of this application Figure 1 ,like Figure 1 As shown, the method includes:

[0103] Step 11: Obtain the real-time service request sequence for HSM and the real-time operating information of the vehicle;

[0104] In this step, the HSM can be a secure hardware unit within the vehicle used to carry out cryptographic operations, key management, identity authentication support, secure communication support, and firmware verification support. The deployment location can be inside the vehicle SoC or in a separate security chip connected to the electronic control unit.

[0105] The real-time service request sequence for HSM can be a set of continuous service calls to or called by HSM within a preset running time window (e.g., within the current time period), and can at least include: the distribution of operation load and request type arranged in chronological order; real-time running information can be collected through the vehicle's CAN bus, Ethernet, or dedicated sensor network, including the vehicle's kinematic parameters and system status indicators at the current moment.

[0106] The collected real-time service request sequence and real-time operation information are formatted, timestamped, and temporarily stored in the vehicle's cache or shared memory area for subsequent processing steps.

[0107] To ensure the timeliness and consistency of the data, step 11 can also preprocess the acquired data. Preprocessing operations may include: deduplicating the real-time service request sequence, aligning it by time window, and filtering and smoothing outliers in the real-time running information. The preprocessed data is organized into a unified data structure and used as the input data source for the AI ​​detection engine.

[0108] Step 12: Using the AI ​​detection engine in the vehicle, perform reasoning processing on the real-time service request sequence and real-time operation information to obtain the target safety evaluation data of the HSM;

[0109] The AI ​​detection engine is equipped with a detection model trained based on multiple service request sequences, multiple operational information, and multiple labeled security evaluation data.

[0110] In this step, the AI ​​detection engine in the vehicle performs inference calculations based on the acquired real-time service request sequence and real-time operational information.

[0111] The AI ​​detection engine is loaded with a pre-trained detection model. This model is built on a large amount of historical data and can map and output corresponding security evaluation data based on the input service request sequence and operation information.

[0112] During the inference process, the AI ​​detection engine calls its internal matrix operation unit and activation function calculation module to calculate layer by layer according to the network structure and weight parameters of the model, and finally generates target security evaluation data that quantifies the current security status of HSM. This target security evaluation data is output in numerical form to characterize the degree of deviation between the current service request behavior and the normal operation mode.

[0113] When performing inference, the AI ​​detection engine first selects the corresponding target model from the detection model set based on the vehicle operating status field in the real-time operating information. The specific implementation method can be found in the detailed description of steps 21 and 22 below.

[0114] Optionally, the corresponding operational information includes: vehicle speed data and vehicle operating status; vehicle operating status includes: driving status, parking status, and OTA upgrade status;

[0115] Accordingly, the detection models include: a first model for driving status, a second model for parking status, and a third model for OTA upgrade status.

[0116] The first model is obtained by training a Long Short-Term Memory (LSTM) network based on multiple vehicle speed data, multiple service request sequences, and multiple labeled safety evaluation data under driving conditions; the second model is obtained by training an LSTM network based on multiple service request sequences and multiple labeled safety evaluation data under parking conditions; and the third model is obtained by training an LSTM network based on multiple vehicle speed data, multiple service request sequences, and multiple labeled safety evaluation data under OTA upgrade conditions.

[0117] In this implementation, 1) the first model adopts an LSTM structure, and its training sample set consists of multiple sets of historical vehicle speed data, historical service request sequences, and corresponding labeled safety evaluation data under driving conditions. During training, the LSTM network learns the temporal dependency between dynamic changes in vehicle speed and service request sequences, and fits it to the labeled safety evaluation data.

[0118] 2) The second model also uses the LSTM structure. Its training is based only on the historical service request sequence and the corresponding labeled safety evaluation data in the parking state, without including vehicle speed data input.

[0119] 3) The third model adopts an LSTM structure, and its training sample set consists of historical vehicle speed data, historical service request sequences, and corresponding labeled safety evaluation data under OTA upgrade status.

[0120] The number of network layers, the number of hidden units, and the training hyperparameters of the three models can be configured according to the size of their respective training datasets, and the corresponding model parameters will be stored in the vehicle's storage area after training is completed.

[0121] It should be understood that training or updating the detection model can also be implemented on the server side, transmitted and saved to the vehicle's storage area through encryption and other means for later use.

[0122] Furthermore, after step 12, the following can also be performed:

[0123] Step 1: Based on the target security evaluation data and real-time operation information, the AI ​​detection engine generates an evidence collection data package, which includes: abnormal event type, timestamp, security evaluation data, vehicle identification code, and HSM identifier.

[0124] In this implementation, after the target security evaluation data is calculated as described above, the AI ​​detection engine generates an evidence data package for recording details of abnormal events based on the target security evaluation data and the real-time operation information collected in step 11.

[0125] For example, the AI ​​detection engine first determines whether the target security evaluation data triggers an abnormal condition (i.e., whether it triggers the implementation of protective processing for the HSM). If it does, it extracts the abnormal event type, the precise timestamp, the target security evaluation data, the vehicle identification number, and the unique identifier of the currently invoked HSM.

[0126] Then, these fields are assembled according to a predefined data packet format to generate a structured forensic data packet, which can be encoded in binary or JSON format and has a checksum field added to ensure data integrity.

[0127] Step 2: Sign the evidence data packet using HSM and store the signed evidence data packet in non-volatile memory;

[0128] In this implementation, the AI ​​detection engine sends the forensic data packet generated in step 1 to the signature interface of HSM. After receiving the forensic data packet, HSM calls its internal asymmetric encryption engine and uses its own private key (e.g., ECDSA P-256) to perform digital signature operation on the hash value of the forensic data packet to generate signature data.

[0129] Subsequently, the HSM merges and packages the original forensic data packet with the generated signature data to form a signed forensic data packet. This signed forensic data packet is written into the vehicle's non-volatile memory via the HSM's storage controller. This non-volatile memory can be embedded flash memory or EEPROM, and it is stored according to a preset storage index structure to support subsequent query and read operations.

[0130] Step 3: When the storage utilization rate of the non-volatile memory reaches the preset threshold, the signed evidence data packet is uploaded through the encrypted channel used for communication in the vehicle.

[0131] In this implementation, the current storage utilization rate of the non-volatile memory is continuously monitored. When the storage utilization rate reaches or exceeds a preset utilization threshold (e.g., 80%), the upload process is triggered.

[0132] The vehicle establishes an encrypted communication channel with the cloud server through its built-in communication module (e.g., T-Box). This encrypted communication channel can be based on TLS or DTLS protocols and use the vehicle's digital certificate for two-way authentication. Through this encrypted communication channel, the vehicle reads the signed evidence data packets stored in non-volatile memory in batches and uploads them to the server.

[0133] After the upload is complete, the vehicle can delete the successfully uploaded evidence data package to free up storage space.

[0134] Step 13: Based on the target security assessment data, perform protective measures on the HSM.

[0135] In this step, based on the target security evaluation data obtained in step 12 above, the corresponding processing measures are selected from a number of preset protection processing strategies and executed to achieve protection processing of HSM.

[0136] The numerical range of the target security evaluation data determines the level of protection. By comparing the target security evaluation data with multiple preset thresholds, the specific protection operation to be performed is determined. The specific implementation of this step can be found in the detailed description of steps 31 to 34 below.

[0137] The HSM protection method provided in this application acquires the real-time service request sequence of the HSM and the real-time operation information of the vehicle. Using an AI detection engine in the vehicle, the real-time service request sequence and real-time operation information are processed for inference to obtain target security evaluation data for the HSM. The AI ​​detection engine is equipped with a detection model trained based on multiple service request sequences, multiple operation information sets, and multiple labeled security evaluation data sets. Based on the target security evaluation data, protection processing is applied to the HSM. This technical solution, by acquiring the real-time service request sequence of the HSM and vehicle operation information, and using the pre-trained detection model in the AI ​​detection engine for comprehensive inference, enables efficient and dynamic security assessment of the HSM's operational status. Based on the obtained target security evaluation data, corresponding protection mechanisms can be automatically triggered, thereby promptly identifying potential abnormal behaviors and executing targeted responses without interrupting normal business operations. This effectively enhances the HSM's anti-interference and anti-attack capabilities during operation, while reducing reliance on manual intervention.

[0138] Based on the above embodiments, Figure 2 Flowchart of the HSM protection method provided in the embodiments of this application Figure 2 ,like Figure 2 As shown, step 12 can be implemented as follows:

[0139] Step 21: Based on the vehicle operating status in the real-time operating information, determine the target model in the detection model;

[0140] The target model can be any one of the first model, the second model, and the third model.

[0141] In this step, the AI ​​detection engine parses the vehicle operating status field from the real-time operating information obtained in step 11 and compares the value of this field with the predefined status identifiers (i.e., the identifiers of driving status, parking status, and OTA upgrade status mentioned above).

[0142] If the vehicle is in a driving state, the first model is selected as the target model; if it is in a parked state, the second model is selected as the target model; if it is in an OTA upgrade state, the third model is selected as the target model.

[0143] If the real-time operation information does not explicitly indicate the above three states, the AI ​​detection engine will automatically determine the current state based on auxiliary conditions such as whether the vehicle speed data is zero and whether the OTA upgrade flag is set, and select the corresponding model as the target model accordingly.

[0144] Step 22: Input the real-time service request sequence and the vehicle speed data from the real-time operation information required by the target model into the target model to obtain the target safety evaluation data.

[0145] In this step, after determining the target model, the AI ​​detection engine takes the real-time service request sequence obtained in step 11 as a mandatory input, and selectively inputs vehicle speed data (determined based on the input parameters of the actual target model) according to the type of the selected target model.

[0146] Specifically, if the target model is the first or third model, the AI ​​detection engine extracts the vehicle speed data at the current moment from the real-time operation information and inputs it along with the real-time service request sequence into the target model; if the target model is the second model, the AI ​​detection engine only inputs the real-time service request sequence into the target model, and the vehicle speed data does not participate in the inference calculation. The target model performs forward calculation according to its trained network structure and parameters, and outputs target safety evaluation data.

[0147] Optionally, step 22 can be implemented as follows:

[0148] Step 1: Based on the real-time service request sequence and the vehicle speed data in the real-time operation information required under the target model, determine the first score, the second score, and the third score.

[0149] Among them, the first score is the standardized deviation score of the request frequency, the second score is the sequence reconstruction loss score of LSTM, and the third score is the cumulative deviation score of the real-time service request sequence over multiple time windows.

[0150] In this implementation, the target model calculates three independent scoring items in parallel or sequentially based on the input real-time service request sequence and optional vehicle speed data, namely the first score, the second score, and the third score.

[0151] 1) For the first score (standardized deviation score of request frequency):

[0152] The target model first counts the frequency of each type of request in the real-time service request sequence and calculates the deviation between it and the historical average request frequency learned during the training phase. This deviation is standardized by subtracting the historical mean from the current frequency and then dividing by the historical standard deviation to obtain the standardized deviation value, which is the first score.

[0153] 2) For the second score (LSTM sequence reconstruction loss score):

[0154] The target model uses its encoder-decoder structure to reconstruct the input sequence. The encoder compresses the input sequence into a context vector, and the decoder expands the vector into a reconstructed sequence. The mean squared error or cross-entropy loss between the input sequence and the reconstructed sequence at each time step is calculated. The loss values ​​of all time steps are accumulated and averaged to obtain the second score.

[0155] 3) For the third rating (cumulative deviation rating over multiple time windows):

[0156] The target model divides the input real-time service request sequence and speed data into multiple sliding time windows of different lengths. Within each window, it calculates the statistical characteristics of the request sequence (e.g., mean, variance, autocorrelation coefficient) and compares them with the baseline statistical characteristics corresponding to each window during the training phase. It calculates the deviation of each window and then weights and sums the deviations of all windows to obtain the third score.

[0157] The target model's network structure contains dedicated output branches for calculating the three scores mentioned above. Each branch consists of an independent fully connected layer that shares the hidden states of the backbone LSTM layer.

[0158] It should be understood that in the above implementation, multiple labeled security evaluation data may include: first labeled score, second labeled score, third labeled score, and data after weighted fusion of labeled data.

[0159] Furthermore, for scenarios that do not include vehicle speed data input (e.g., the second model), the calculation of the third score is based solely on windowing and statistical feature comparison of the real-time service request sequence.

[0160] Step 2: The first score, second score, and third score are weighted and fused using the target model to obtain the target safety evaluation data.

[0161] In this implementation, the target model takes the first score, second score, and third score calculated in step 1 as input and performs a weighted linear combination through its internal fusion layer.

[0162] The fusion layer can store preset weight coefficients, each corresponding to one of the three scores. The fusion layer performs a weighted summation operation, i.e., target security evaluation data = weight 1 × first score + weight 2 × second score + weight 3 × third score.

[0163] Each weight coefficient is determined during the training phase of the detection model through the backpropagation algorithm in conjunction with other network parameters. The weighted summation result of the fusion layer output serves as the final target security evaluation data and is transmitted to the output interface of the AI ​​detection engine.

[0164] The HSM protection method provided in this application determines the target model in the detection model based on the vehicle operating status in the real-time operation information. The target model can be any one of the first model, the second model, and the third model. The real-time service request sequence and the vehicle speed data in the real-time operation information required by the target model are input into the target model to obtain the target safety evaluation data. In this technical solution, the corresponding dedicated LSTM model is accurately matched and called according to the vehicle operating status in the real-time operation information, and only the feature data required in that state is input. This ensures that the input space of the detection model inference is strictly aligned with the actual operating conditions of the current vehicle, thereby effectively avoiding noise interference and model misjudgment by irrelevant feature data in the safety evaluation. At the same time, by reducing redundant input data, the computational overhead and memory usage of the AI ​​detection engine are reduced. Ultimately, a high-precision, low-latency, and resource-adaptive dynamic safety risk assessment of HSM service request behavior is achieved under different vehicle operating scenarios.

[0165] Based on the above embodiments, Figure 3 Flowchart of the HSM protection method provided in the embodiments of this application Figure 3 ,like Figure 3 As shown, step 13 can be implemented using any of the following steps:

[0166] Step 31: If the target security evaluation data is less than or equal to the first preset threshold, perform the first protection treatment on the HSM;

[0167] The first protective measure is to continuously monitor HSM through an AI detection engine;

[0168] In this step, when the target security assessment data is less than or equal to the first preset threshold, the current HSM's security risk level is determined to be the lowest level.

[0169] At this point, the AI ​​detection engine is kept in its current monitoring state and no intervention is performed on the HSM. The AI ​​detection engine is only required to continue monitoring the HSM's operating status at the normal sampling frequency.

[0170] For example, the continuous monitoring operation includes continuing to execute the cycle of steps 11 to 12 to track the changing trend of the target safety assessment data in real time.

[0171] Step 32: If the target security evaluation data is greater than the first preset threshold and less than or equal to the second preset threshold, perform the second protection treatment on the HSM;

[0172] The second protective measure involves increasing the sampling frequency of the AI ​​detection engine and recording alarm logs.

[0173] In this step, when the target safety evaluation data is greater than the first preset threshold and less than or equal to the second preset threshold, it is determined that the HSM has a slight anomaly.

[0174] At this point, a sampling frequency adjustment command is sent to the AI ​​detection engine. In response to the command, the AI ​​detection engine shortens its internal data acquisition and inference execution cycle (e.g., to 60% of the original cycle) and increases the sampling frequency (e.g., from once every 100 milliseconds to once every 50 milliseconds) to obtain more intensive monitoring data.

[0175] At the same time, the logging service is invoked to write the current target security assessment data, timestamp, and trigger event type into the alarm log file, which is stored in non-volatile memory.

[0176] Step 33: If the target security evaluation data is greater than the second preset threshold and less than or equal to the third preset threshold, perform third protection processing on the HSM;

[0177] The third protection process involves controlling the HSM to perform a key rotation and, after the rotation, controlling the AI ​​detection engine to send a recovery confirmation token to the HSM.

[0178] In this step, when the target security evaluation data is greater than the second preset threshold and less than or equal to the third preset threshold, the HSM has a moderate anomaly.

[0179] At this point, a key rotation command is sent to the HSM. Upon receiving the command, the HSM generates a new key pair or symmetric key in its internal security processor to replace the currently used session key or communication key. After the key rotation is completed, the HSM sends a key update notification to the AI ​​detection engine. This notification contains the version information and activation timestamp of the new key. Upon receiving the notification, the AI ​​detection engine re-collects the real-time service request sequence and operation information for the current period based on the new key environment, and recalculates the baseline security evaluation data using its internally deployed detection model to complete the baseline reconstruction of the normal operation mode under the new key environment.

[0180] After the baseline reconstruction is completed, the AI ​​detection engine generates a recovery confirmation token. This recovery confirmation token contains the current timestamp, the new key version number, and the digital signature of the AI ​​detection engine. It is then sent to the HSM through a secure channel. Upon receiving the recovery confirmation token, the HSM verifies the validity of its digital signature, timestamp, and version number. Once the verification is successful, the HSM exits the current degraded working mode and restores normal service response capabilities.

[0181] Step 34: If the target security evaluation data is greater than the third preset threshold, perform the fourth protection process on the HSM;

[0182] The fourth protection process involves controlling the HSM to destroy the temporary session key and enter a fully isolated mode, as well as sending an emergency alarm.

[0183] In this step, when the target security evaluation data is greater than the third preset threshold, it is determined that the HSM has a serious anomaly.

[0184] At this point, a command to destroy the temporary session key is immediately sent to the HSM. The HSM executes the command, physically erasing all temporary session keys stored internally. Subsequently, the HSM stops responding to all non-privileged service requests, shuts down its external communication interface, and enters a fully isolated mode.

[0185] At the same time, an emergency alarm message is sent to the vehicle manufacturer's monitoring center or user terminal through the vehicle communication module. This emergency alarm message may include: vehicle identification number, time of anomaly occurrence, and information on isolation measures already implemented.

[0186] The HSM protection method provided in this application embodiment performs the following steps: if the target security evaluation data is less than or equal to a first preset threshold, a first protection process is performed on the HSM, which involves continuously monitoring the HSM through an AI detection engine; if the target security evaluation data is greater than the first preset threshold and less than or equal to a second preset threshold, a second protection process is performed on the HSM, which involves increasing the sampling frequency of the AI ​​detection engine and recording alarm logs; if the target security evaluation data is greater than the second preset threshold and less than or equal to a third preset threshold, a third protection process is performed on the HSM, which involves controlling the HSM to perform key rotation and, after rotation, controlling the AI ​​detection engine to send a recovery confirmation token to the HSM; if the target security evaluation data is greater than the third preset threshold, a fourth protection process is performed on the HSM, which involves controlling the HSM to destroy the temporary session key and enter a fully isolated mode, and sending an emergency alarm. This technical solution divides the security risks of HSM into four progressively increasing severity levels by setting first, second, and third preset thresholds. For each level, it configures a progressively enhanced differentiated protection strategy, from continuous monitoring to increasing sampling frequency and recording alarm logs, then to performing key rotation and sending recovery confirmation tokens, and finally to destroying temporary session keys, entering full isolation mode, and sending emergency alarms. This allows the strength of the protection measures to be precisely and dynamically matched with the real-time assessed security risk level. It can maintain system operating efficiency and minimize resource consumption when the risk is low, and can block attack links in a timely manner through gradual intervention when the risk gradually increases. At the highest risk, it can achieve the ultimate defense in depth through key destruction and physical isolation.

[0187] Based on the above embodiments, Figure 4 Flowchart of the HSM protection method provided in the embodiments of this application Figure 4 ,like Figure 4 As shown, before step 21, the following can also be performed:

[0188] Step 41: Perform integrity verification on the model parameters of the detection model deployed in the AI ​​detection engine using HSM;

[0189] The integrity verification includes: HSM using its own private key to decrypt the pre-stored key ciphertext to obtain the symmetric key, using the symmetric key to decrypt the pre-stored parameter ciphertext to obtain the plaintext parameter, and calculating the first hash value of the plaintext parameter, and comparing the first hash value with the pre-stored reference hash value.

[0190] In this step, before the target model is determined in step 21, HSM performs an integrity check on the model parameters of the detection model deployed in the AI ​​detection engine.

[0191] The HSM reads the pre-stored ciphertext key from its secure storage area, decrypts it using its own private key, and obtains the symmetric key. Then, the HSM uses this symmetric key to symmetrically decrypt the pre-stored ciphertext parameters, obtaining the model parameters in plaintext form. The HSM applies a hash algorithm (e.g., SHA-256) to the decrypted plaintext model parameters to calculate its first hash value.

[0192] After the calculation is complete, HSM compares the first hash value bit by bit with the reference hash value pre-stored in the HSM secure storage area. If they match, the integrity check passes; otherwise, the check fails, HSM stops the subsequent loading process and logs the error event.

[0193] In addition, HSM can also verify the OEM CA signature (such as RSA, ECDSA, etc.) of the encrypted parameters to ensure the legitimacy of the model parameters. If the hash values ​​are inconsistent or the CA signature verification fails, HSM will refuse to load the model and log the error event.

[0194] Optionally, before step 41, the following can also be performed:

[0195] Step 1: Obtain the parameter ciphertext, key ciphertext, reference hash value, and vehicle manufacturer CA signature through the vehicle's OTA secure channel used for communication.

[0196] Among them, the parameter ciphertext is obtained by encrypting the model parameters with a random symmetric key, the key ciphertext is obtained by encrypting the random symmetric key with the public key of the HSM, and the OEM CA signature is used to verify the source of the detection model when the vehicle is updated over OTA.

[0197] In this implementation, before the integrity verification in step 41, the vehicle establishes a secure channel with the OEM's OTA server through its OTA communication module. Through this secure channel, the vehicle receives parameter ciphertext, key ciphertext, reference hash value, and OEM CA signature issued by the OEM.

[0198] The parameter ciphertext is obtained by the vehicle manufacturer using a randomly generated symmetric key to symmetrically encrypt the latest model parameters in an offline environment. The key ciphertext is obtained by the vehicle manufacturer using the public key of the HSM to asymmetrically encrypt the random symmetric key. The vehicle manufacturer's CA signature is a digital signature generated by the vehicle manufacturer using its private key to sign the digest of the above data packet.

[0199] After receiving the above data, the vehicle first uses the pre-installed OEM CA root certificate to verify the CA signature to confirm that the data source is legitimate and has not been tampered with.

[0200] Step 2: Write the parameter ciphertext, key ciphertext, reference hash value, and vehicle manufacturer CA signature into the secure storage area of ​​the HSM.

[0201] In this implementation, after verifying the OEM CA signature, the vehicle writes the parameter ciphertext, key ciphertext, reference hash value, and OEM CA signature received in step 1 into the secure storage area of ​​the HSM.

[0202] The HSM stores the aforementioned data in a flash memory area with access protection mechanisms within it. This area can only be read and written by the HSM itself in privileged mode, and external entities cannot access it directly. After storage is completed, the HSM creates an index with the corresponding version number to support subsequent reading and calling in step 41.

[0203] Step 42: After the integrity verification is passed, a temporary session key is generated through negotiation between HSM and AI detection engine, and the model parameters are encrypted and transmitted to AI detection engine using the temporary session key.

[0204] In this step, after the integrity verification in step 41 passes, the HSM and the AI ​​detection engine perform a temporary session key negotiation process.

[0205] Based on ECDH or a pre-set shared key mechanism, both parties exchange random numbers and calculate and generate a temporary session key through a handshake protocol. After the negotiation is completed, the HSM uses the temporary session key to symmetrically encrypt the plaintext model parameters obtained in step 41 and transmits the encrypted model parameters to the AI ​​detection engine through the vehicle's internal security bus.

[0206] After receiving the encrypted parameters, the AI ​​detection engine decrypts them using the same temporary session key, recovers the plaintext model parameters, and loads the model parameters into the memory space of its inference engine to complete the deployment of the target model.

[0207] Optionally, after the transmission is complete, both the HSM and the AI ​​detection engine destroy the temporary session key to reduce the risk of leakage.

[0208] The HSM protection method provided in this application embodiment performs integrity verification on the model parameters of the detection model deployed in the AI ​​detection engine through the HSM. The integrity verification includes: the HSM decrypts the pre-stored key ciphertext using its own private key to obtain a symmetric key, decrypts the pre-stored parameter ciphertext using the symmetric key to obtain plaintext parameters, and calculates the first hash value of the plaintext parameters, comparing the first hash value with a pre-stored reference hash value; after the integrity verification is passed, the HSM negotiates with the AI ​​detection engine to generate a temporary session key, and uses the temporary session key to encrypt and transmit the model parameters to the AI ​​detection engine. This technical solution utilizes the HSM's private key to decrypt the ciphertext of the key to obtain the symmetric key, and then uses the symmetric key to decrypt the ciphertext of the parameters to obtain the plaintext parameters. A first hash value is calculated for the plaintext parameters and compared with a pre-stored reference hash value. This achieves hardware-level trusted verification of the authenticity, integrity, and tamper-proof nature of the model parameters in an untrusted environment. Since both decryption and signature verification operations are completed within the secure execution environment of the HSM, it effectively prevents the key and plaintext parameters from being stolen by system software or malicious processes during verification. After the integrity verification passes, the HSM negotiates with the AI ​​detection engine to generate a temporary session key and uses this temporary session key to encrypt and transmit the model parameters. This ensures the confidentiality and session uniqueness of the model parameters throughout the entire transmission process from the HSM's secure storage area to the AI ​​detection engine's memory. Even if the transmission link is intercepted, the plaintext parameters cannot be decrypted. Furthermore, using a different temporary key for each transmission avoids the replay attack risk caused by key reuse, fundamentally preventing the systemic risk of HSM security evaluation failure or security decision bypass due to model parameter tampering or theft.

[0209] Based on the above embodiments, Figure 5 Flowchart of the HSM protection method provided in the embodiments of this application Figure 5 ,like Figure 5 As shown, a possible complete implementation could be:

[0210] Step 51: Secure initialization of the detection model in the AI ​​detection engine:

[0211] The OEM's security platform uses the HSM public key PK_HSM to encrypt the detection model parameter W: First, it uses a random symmetric key K_sym to perform AES-256-GCM encryption to obtain ciphertext C_W (parameter ciphertext), then uses PK_HSM to encrypt K_sym to obtain E_sym (key ciphertext), calculates HMAC-SHA256(W) to obtain hash H_W (parameter hash value), and writes {C_W, E_sym, H_W} into the secure storage area of ​​HSM through the OTA secure channel. At the same time, it writes the OEM CA signature Sig_CA (OEM CA signature) to verify the source of the detection model during OTA updates.

[0212] Step 52, Integrity Verification and Security Activation Before Inference:

[0213] Before each inference, the AI ​​detection engine sends a verification request to the HSM. Within the security boundary, the HSM uses SK_HSM to decrypt E_sym to obtain K_sym, and then decrypts C_W to obtain plaintext W (plaintext parameters). It calculates HMAC-SHA256(W) (the first hash value) and compares it with H_W. After the verification is successful, the HSM negotiates with the detection model to generate a temporary session key K_session, and transmits W (model parameters) to the AI ​​detection engine through an encrypted channel.

[0214] Step 53, Runtime Behavior Monitoring and Anomaly Scoring:

[0215] The AI ​​detection engine collects (real-time) service request sequences from the HSM (e.g., request type, source functional domain ID, timestamp) from CAN / CAN-FD / vehicle Ethernet, and simultaneously collects real-time operating information (vehicle speed, operating mode, and other status parameters). Based on the current state, it selects the corresponding time-series feature sub-model (i.e., the models corresponding to M1 driving / M2 parking / M3-OTA upgrade, etc.) and calculates three-dimensional scores: S_freq (frequency standardization deviation, i.e., the first score), S_seq (LSTM sequence reconstruction loss, i.e., the second score), and S_acc (multi-window cumulative deviation, i.e., the third score), and then weights them to obtain the Score (target safety evaluation data).

[0216] Step 54, Graded Self-Healing Response:

[0217] Score below th0 (first preset threshold): Normal, continue monitoring; th0 to th1 (level 1) (second preset threshold): Record alarm logs and increase sampling frequency; th1 to th2 (level 2) (third preset threshold): HSM performs key rotation, sends key update notification, AI rebuilds baseline, AI sends recovery confirmation, HSM exits degrade mode, forming a closed loop; Score above th2 (level 3): HSM destroys temporary session key, enters full isolation mode, sends emergency alarm to OEM, and waits for OEM CA signature recovery instruction before exiting isolation.

[0218] Step 55, Trusted Evidence Collection and Reporting:

[0219] AI encapsulates the evidence collection data packet FP, submits it to HSM to sign with ECDSA P-256 private key, and persistently writes it to FRAM; when the FRAM usage exceeds 80% (the preset usage threshold), an emergency batch report is triggered and reported to the vehicle manufacturer's security platform via TLS 1.3. The platform verifies the signature with PK_HSM and completes non-repudiable evidence storage.

[0220] The evidence collection data packet (FP) may include at least the following fields, such as event_type, timestamp, anomaly_score, VIN, and hsm_id.

[0221] Step 56, Federated Learning Collaborative Update:

[0222] Each vehicle calculates its gradient locally, adds differential privacy noise, and then reports it to the OEM's TEE environment. After FedAvg aggregation, CA signs and issues a new model (which can be the model or model parameters). The vehicle can only be officially switched after the isolation sandbox verification function is completed. If the verification fails, the old version is automatically rolled back, and HSM restores the old copyright weights from the backup area.

[0223] Based on the above solution, this application has the following technical effects:

[0224] Technical effect 1: Effectively detects attacks that are abnormally driven by the runtime HSM interface, making up for the blind spots of static integrity measurement;

[0225] Technical effect 1: The detection model itself has anti-tampering capabilities, and attackers cannot bypass the detection by modifying the model parameters;

[0226] Technical effect 2: State-specific modeling significantly reduces the false alarm rate compared to a single global threshold scheme;

[0227] Technical effect 3: Multi-window cumulative scoring effectively identifies low-frequency, slow attacks (low single score but abnormally high cumulative score).

[0228] Technical effect 4: The closed-loop self-healing mechanism reduces the attack response time from several hours (manual intervention) to seconds (automatic closed loop).

[0229] Technical effect 5: The evidence data is tamper-proof and non-repudiable, meeting the requirements of judicial evidence collection and regulatory compliance;

[0230] Technical benefit 6: Federated learning enables the detection model to continuously evolve to cope with new attacks, while protecting the privacy of the original data of each vehicle.

[0231] The reasons for the above technical effects are analyzed as follows:

[0232] 1) The HSM hardware security boundary ensures the confidentiality and integrity of model parameters: AES-256-GCM encryption + HMAC-SHA256 measurement are completed inside the HSM. Even if an attacker gains SoC privileges, they cannot read or modify the plaintext of the model. Therefore, the detection capability is not affected by the attack.

[0233] 2) Temporal modeling can capture changes in behavioral patterns: LSTM / Transformer models the transition probability of the call sequence and can perceive deviations in three dimensions: request type, frequency, and order, covering a wider attack surface than simple frequency rate limiting.

[0234] 3) State-based sub-model eliminates interference from legitimate business fluctuations: Normal baselines are maintained independently under different driving conditions, and scores are compared only under the same condition, eliminating false alarms caused by state switching and improving detection accuracy;

[0235] 4) The closed-loop protocol ensures that the self-healing process is verifiable: HSM sends a notification containing a new environment identifier. After AI rebuilds the baseline in the new environment, it sends back a confirmation token containing the baseline version number. HSM verifies the version number to confirm that the baseline matches the new key environment, thus eliminating the risk of false recovery caused by baseline contamination.

[0236] 5) The ECDSA private key is stored within the HSM hardware security boundary and cannot be exported. The signing operation is completed inside the HSM to ensure the authenticity of the signature, thereby ensuring the immutability and legal validity of the evidence data.

[0237] Based on the above embodiments, Figure 6 This is a schematic diagram of the structure of the protective device for HSM provided in the embodiments of this application, as shown below. Figure 6 As shown, the device includes:

[0238] The acquisition module 61 is used to acquire the real-time service request sequence of HSM in the vehicle and the real-time operation information of the vehicle.

[0239] The first processing module 62 is used to perform reasoning processing on the real-time service request sequence and real-time operation information through the AI ​​detection engine in the vehicle to obtain the target safety evaluation data of HSM. The AI ​​detection engine is equipped with a detection model trained based on multiple service request sequences, multiple operation information, and multiple labeled safety evaluation data.

[0240] The second processing module 63 is used to perform protection processing on the HSM based on the target security evaluation data.

[0241] In one or more embodiments, the corresponding operational information includes: vehicle speed data and vehicle operating status; the vehicle operating status includes: driving status, parking status, and OTA upgrade status;

[0242] Accordingly, the detection models include: a first model for driving status, a second model for parking status, and a third model for OTA upgrade status.

[0243] The first model is obtained by training an LSTM based on multiple vehicle speed data, multiple service request sequences, and multiple labeled safety evaluation data under driving conditions; the second model is obtained by training an LSTM based on multiple service request sequences and multiple labeled safety evaluation data under parking conditions; and the third model is obtained by training an LSTM based on multiple vehicle speed data, multiple service request sequences, and multiple labeled safety evaluation data under OTA upgrade conditions.

[0244] In one or more embodiments, the first processing module 62 is specifically used for:

[0245] Based on the vehicle operating status in the real-time operation information, the target model is determined in the detection model. The target model is any one of the first model, the second model, and the third model.

[0246] The real-time service request sequence and vehicle speed data from the real-time operational information required by the target model are input into the target model to obtain target safety evaluation data.

[0247] In one or more embodiments, the first processing module 62 inputs the real-time service request sequence and the vehicle speed data from the real-time operating information required by the target model into the target model to obtain target safety evaluation data, specifically for:

[0248] Based on the real-time service request sequence and the vehicle speed data in the real-time operation information required by the target model, the first score, the second score, and the third score are determined. The first score is the standardized deviation score of the request frequency, the second score is the sequence reconstruction loss score of LSTM, and the third score is the cumulative deviation score of the real-time service request sequence in multiple time windows.

[0249] The target safety evaluation data is obtained by weighting and fusing the first, second, and third scores using the target model.

[0250] In one or more embodiments, the second processing module 63 performs protection processing on the HSM based on the target security evaluation data, specifically for:

[0251] If the target security evaluation data is less than or equal to the first preset threshold, the HSM is subjected to the first protection process, which is to continuously monitor the HSM through the AI ​​detection engine.

[0252] If the target security evaluation data is greater than the first preset threshold and less than or equal to the second preset threshold, the HSM will be subjected to a second protection process, which is to increase the sampling frequency of the AI ​​detection engine and record alarm logs.

[0253] If the target security evaluation data is greater than the second preset threshold and less than or equal to the third preset threshold, the HSM is subjected to third protection processing. The third protection processing is to control the HSM to perform key rotation and, after rotation, control the AI ​​detection engine to send a recovery confirmation token to the HSM.

[0254] If the target security evaluation data exceeds the third preset threshold, the HSM will be subjected to a fourth protection process. The fourth protection process is to control the HSM to destroy the temporary session key and enter a fully isolated mode, and to send an emergency alarm.

[0255] In one or more embodiments, before obtaining the target safety evaluation data of the HSM by reasoning through the AI ​​detection engine in the vehicle on the real-time service request sequence and real-time operation information, the first processing module 62 is further configured to:

[0256] The integrity of the model parameters of the detection model deployed in the AI ​​detection engine is verified by HSM. The integrity verification includes: HSM using its own private key to decrypt the pre-stored key ciphertext to obtain the symmetric key, using the symmetric key to decrypt the pre-stored parameter ciphertext to obtain the plaintext parameter, and calculating the first hash value of the plaintext parameter, and comparing the first hash value with the pre-stored reference hash value.

[0257] After the integrity verification is passed, a temporary session key is generated through negotiation between the HSM and the AI ​​detection engine, and the model parameters are encrypted and transmitted to the AI ​​detection engine using the temporary session key.

[0258] In one or more embodiments, before performing integrity verification on the model parameters of the detection model deployed in the AI ​​detection engine via HSM, the first processing module 62 is further configured to:

[0259] The vehicle obtains parameter ciphertext, key ciphertext, reference hash value, and OEM CA signature through the OTA security channel used for vehicle communication. The parameter ciphertext is obtained by encrypting the model parameters with a random symmetric key, the key ciphertext is obtained by encrypting a random symmetric key with the HSM public key, and the OEM CA signature is used to verify the source of the detection model when the vehicle is updated via OTA.

[0260] Write the parameter ciphertext, key ciphertext, reference hash value, and OEM CA signature into the secure storage area of ​​the HSM.

[0261] In one or more embodiments, the first processing module 62 is further configured to:

[0262] Based on target security evaluation data and real-time operational information, the AI ​​detection engine generates an evidence collection data package, which includes: abnormal event type, timestamp, security evaluation data, vehicle identification code, and HSM identifier.

[0263] The evidence collection data packets are signed using HSM, and the signed evidence collection data packets are stored in non-volatile memory;

[0264] When the storage utilization rate of the non-volatile memory reaches a preset threshold, the signed evidence data packet is uploaded through the encrypted channel used for communication in the vehicle.

[0265] It should be noted that the division of the various modules in the above device is merely a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical element, or they can be physically separated. Furthermore, these modules can be implemented entirely in software through processing element calls, or entirely in hardware. Alternatively, some modules can be implemented through processing element calls in software, while others can be implemented in hardware. Moreover, these modules can be integrated together or implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. During implementation, each step of the above method or each of the above modules can be completed through the integrated logic circuits in the hardware of the processor element or through software instructions.

[0266] As can be seen from the above, the HSM protection device provided in this embodiment can perform the method provided in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be described in detail here.

[0267] Figure 7 This is a structural schematic diagram of a vehicle provided in an embodiment of this application. Figure 7 As shown, the vehicle provided in this embodiment includes at least one processor 71 and a memory 72.

[0268] Optionally, the vehicle also includes a communication component 73.

[0269] The processor 71, memory 72, and communication component 73 are connected via bus 74.

[0270] In a specific implementation, at least one processor 71 executes computer execution instructions stored in memory 72, causing at least one processor 71 to perform the above-described method.

[0271] The specific implementation process of processor 71 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0272] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0273] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0274] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0275] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0276] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0277] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0278] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0279] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0280] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0281] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0282] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0283] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0284] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for protecting HSMs, characterized in that, include: Obtain the real-time service request sequence for HSM in the vehicle and the real-time operating information of the vehicle; The AI ​​detection engine in the vehicle performs inference processing on the real-time service request sequence and the real-time operation information to obtain the target security evaluation data of the HSM. The AI ​​detection engine is equipped with a detection model trained based on multiple service request sequences, multiple operation information, and multiple labeled security evaluation data. Based on the target security evaluation data, the HSM is subjected to protective measures.

2. The method according to claim 1, characterized in that, The corresponding operational information includes: vehicle speed data and vehicle operating status; the vehicle operating status includes: driving status, parking status, and OTA upgrade status; Accordingly, the detection model includes: a first model corresponding to the driving state, a second model corresponding to the parking state, and a third model corresponding to the OTA upgrade state; The first model is obtained by training an LSTM based on multiple vehicle speed data, multiple service request sequences, and multiple labeled safety evaluation data under the driving state; the second model is obtained by training an LSTM based on multiple service request sequences and multiple labeled safety evaluation data under the parking state; and the third model is obtained by training an LSTM based on multiple vehicle speed data, multiple service request sequences, and multiple labeled safety evaluation data under the OTA upgrade state.

3. The method according to claim 2, characterized in that, The reasoning process performed on the real-time service request sequence and the real-time operation information to obtain the target security evaluation data of the HSM includes: Based on the vehicle operating status in the real-time operating information, a target model is determined in the detection model. The target model is any one of the first model, the second model, and the third model. The real-time service request sequence and the vehicle speed data from the real-time operation information required under the target model are input into the target model to obtain the target safety evaluation data.

4. The method according to claim 3, characterized in that, The step of inputting the real-time service request sequence and the vehicle speed data from the real-time operating information required under the target model into the target model to obtain the target safety evaluation data includes: The target model determines a first score, a second score, and a third score based on the real-time service request sequence and the vehicle speed data in the real-time operation information required under the target model. The first score is the standardized deviation score of the request frequency, the second score is the sequence reconstruction loss score of LSTM, and the third score is the cumulative deviation score of the real-time service request sequence within multiple time windows. The target security evaluation data is obtained by weighting and fusing the first score, the second score, and the third score using the target model.

5. The method according to any one of claims 1-4, characterized in that, The step of performing protection processing on the HSM based on the target security evaluation data includes: If the target security evaluation data is less than or equal to a first preset threshold, the HSM is subjected to a first protection process, which is to continuously monitor the HSM through the AI ​​detection engine. If the target security evaluation data is greater than the first preset threshold and less than or equal to the second preset threshold, the HSM is subjected to a second protection process, which is to increase the sampling frequency of the AI ​​detection engine and record alarm logs. If the target security evaluation data is greater than the second preset threshold and less than or equal to the third preset threshold, the HSM is subjected to a third protection process. The third protection process is to control the HSM to perform key rotation and, after rotation, control the AI ​​detection engine to send a recovery confirmation token to the HSM. If the target security evaluation data is greater than the third preset threshold, the HSM will be subjected to a fourth protection process, which is to control the HSM to destroy the temporary session key and enter a complete isolation mode, and to send an emergency alarm.

6. The method according to any one of claims 1-4, characterized in that, Before obtaining the target safety evaluation data of the HSM by inferring the real-time service request sequence and the real-time operation information through the AI ​​detection engine in the vehicle, the method further includes: The HSM performs integrity verification on the model parameters of the detection model deployed in the AI ​​detection engine. The integrity verification includes: the HSM decrypts the pre-stored key ciphertext using its own private key to obtain a symmetric key, decrypts the pre-stored parameter ciphertext using the symmetric key to obtain plaintext parameters, calculates the first hash value of the plaintext parameters, and compares the first hash value with a pre-stored reference hash value. After the integrity verification is passed, a temporary session key is generated through negotiation between the HSM and the AI ​​detection engine, and the model parameters are encrypted and transmitted to the AI ​​detection engine using the temporary session key.

7. The method according to claim 6, characterized in that, Before performing integrity verification on the model parameters of the detection model deployed in the AI ​​detection engine via the HSM, the method further includes: The ciphertext of the parameters, the ciphertext of the key, the reference hash value, and the CA signature of the vehicle manufacturer are obtained through the OTA security channel used by the vehicle for communication. The ciphertext of the parameters is obtained by encrypting the model parameters with a random symmetric key. The ciphertext of the key is obtained by encrypting the random symmetric key with the public key of the HSM. The CA signature of the vehicle manufacturer is used to verify the origin of the detection model when the vehicle is updated via OTA. The parameter ciphertext, the key ciphertext, the reference hash value, and the vehicle manufacturer's CA signature are written into the secure storage area of ​​the HSM.

8. The method according to any one of claims 1-4, characterized in that, The method further includes: The AI ​​detection engine generates an evidence collection data package based on the target security evaluation data and the real-time operation information. The evidence collection data package includes: abnormal event type, timestamp, security evaluation data, vehicle identification code, and HSM identifier. The evidence collection data packet is signed by the HSM and the signed evidence collection data packet is stored in non-volatile memory; When the storage utilization rate of the non-volatile memory reaches a preset threshold, the signed evidence data packet is uploaded through the encrypted channel used for communication by the vehicle.

9. A protective device for HSM, characterized in that, include: The acquisition module is used to acquire the real-time service request sequence of HSM in the vehicle and the real-time operation information of the vehicle; The first processing module is used to perform inference processing on the real-time service request sequence and the real-time operation information through the AI ​​detection engine in the vehicle to obtain the target security evaluation data of the HSM. The AI ​​detection engine is equipped with a detection model trained based on multiple service request sequences, multiple operation information, and multiple labeled security evaluation data. The second processing module is used to perform protection processing on the HSM based on the target security evaluation data.

10. A vehicle / computer-readable storage medium / computer program product, characterized in that, The vehicle includes: a memory and a processor; The memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-8; The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-8; The computer program product includes a computer program that, when executed by a processor, is used to implement the method as described in any one of claims 1-8.

Images