A vehicle information security risk threat protection assessment method and electronic device

Abstract

The present application relates to the technical field of vehicle information security, and specifically discloses a vehicle information security risk threat protection evaluation method and electronic equipment, wherein the present application identifies vehicle component security nodes and vehicle component threat behavior nodes, comprehensively analyzes a multi-dimensional security evaluation index system according to the vehicle component threat behavior nodes, determines the security risk level of the vehicle component, outputs a security risk starting process according to the security risk level of the vehicle component by building a hardware security architecture, realizes security boot verification, designs a security flashing process and a security access control process to realize software security protection, realizes unified management, forwarding and execution of security service requests based on a layered software architecture, adopts an encryption task publishing and notification mechanism to realize efficient cooperation with a hardware security module, and realizes full life cycle management of security keys, thereby significantly improving the effectiveness of vehicle information security protection and providing reliable protection for safe operation of vehicles.

Description

Technical Field

[0001] This invention relates to the field of vehicle information security technology, and more specifically, to a method and electronic device for assessing vehicle information security risks and threats. Background Technology

[0002] With the increasing electrification and intelligence of automobiles, vehicle network systems are becoming increasingly complex, involving multiple levels of systems, hardware components, and software components, including the overall vehicle function layer and component layer. Consequently, cybersecurity issues are becoming increasingly prominent. Currently, vehicles face numerous security threats during operation. For example, hackers may exploit debugging interfaces to tamper with software and extract critical information; modify update packages during software flashing to implant malicious programs; alter firmware in Flash memory during the firmware boot phase to affect normal vehicle operation; and unauthorized diagnostic equipment may illegally access important data within the ECU or request diagnostic services that could compromise vehicle safety. These security threats not only lead to vehicle malfunctions but may also endanger the lives and property of passengers. Existing vehicle information security protection measures suffer from incomplete protection, lack of specificity, and insufficient security, failing to meet the needs of vehicle cybersecurity and providing reliable security for various vehicle system components. Therefore, an efficient and secure vehicle information security risk assessment and protection solution is urgently needed to address these issues.

[0003] Therefore, it is necessary to provide a vehicle information security risk and threat protection assessment method and electronic device to solve the above-mentioned technical problems. In order to solve the above problems, a technical solution is provided. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, the present invention provides a vehicle information security risk and threat protection assessment method and electronic device, which addresses the problems that existing vehicle information security protection measures are not comprehensive enough, lack specificity, and have insufficient security, making it difficult to meet the needs of vehicle network security and provide reliable security guarantees for various system components of the vehicle.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A method for assessing vehicle information security risks and threats includes the following steps: Based on vehicle network security specifications, the scope of vehicle information security risk and threat assessment is clearly defined, and vehicle component security nodes and vehicle component threat behavior nodes are identified. A multi-dimensional security assessment index system is constructed based on the threat behavior nodes of vehicle components for comprehensive analysis to determine the security risk level of vehicle components. By building a hardware security architecture, the security risk initiation process is triggered based on the security risk level of the vehicle components, thereby achieving secure boot verification. Furthermore, a secure flashing process and a secure access control process are designed to achieve software security protection. Based on a layered software architecture, it realizes unified management, forwarding and execution of security service requests, adopts an encrypted task publishing and notification mechanism, achieves efficient collaboration with hardware security modules, and realizes full lifecycle management of security keys.

[0006] As a further aspect of the present invention, the scope of vehicle information security risk and threat assessment is clarified based on vehicle network security specifications, and vehicle component security nodes and vehicle component threat behavior nodes are identified. The specific steps are as follows: Based on the vehicle network security specifications, the scope of information security risk and threat assessment for vehicle components is clearly defined. Vehicle components include hardware components, software components and related interfaces, and the corresponding security nodes of vehicle components are identified. Based on the security control attributes captured for each security node i, a set of security control attributes is formed. A predictive behavior model is constructed for each security node based on security control attributes to describe the allowed behavior characteristics of the security node under normal conditions, serving as the first behavior characteristic. By collecting the actual behavioral characteristics of each node during the operation of vehicle components in real time, as the second behavioral characteristic, a safety behavior deviation coefficient analysis model is constructed based on the first and second behavioral characteristics to obtain the behavioral deviation coefficients corresponding to the safety nodes. Abnormal behaviors of security nodes are identified based on behavioral deviation coefficients, and vehicle component threat behavior nodes are generated. A threat list is then established based on these vehicle component threat behavior nodes.

[0007] As a further aspect of the present invention, the security control attribute set is as follows: ,in, For the k-th security control attribute, Total number of security control attributes; The first behavioral characteristic is ,in, For the set of allowed behavior types, The allowed execution time interval, For the allowed frequency range of behavior calls, The permitted permission level range; The second behavioral characteristic is ,in, Characteristics of actual behavior types For the temporal characteristics of actual behavior, This is a characteristic of the frequency of actual behavior calls. This refers to the actual level of access privileges.

[0008] As a further aspect of the present invention, the calculation formula for the safety behavior deviation coefficient analysis model constructed based on the first behavioral feature and the second behavioral feature is as follows: ; In the formula: This is the behavioral deviation coefficient. This is a characteristic of the frequency of actual behavior calls. The number of types of the second behavioral characteristic. For the first The weight of the second behavioral feature of the class. For the first The second behavior of the class is a feature deviation function. For the first Class second behavioral characteristics, For the first The first behavioral characteristic of the class To determine the maximum allowed frequency of behavior calls, The minimum allowed frequency of behavior calls.

[0009] As a further aspect of the present invention, abnormal behavior of security nodes is identified based on behavior deviation coefficients, and vehicle component threat behavior nodes are generated. The specific steps are as follows: Extract the behavior deviation coefficient and compare it with the preset behavior deviation threshold. If the behavior deviation coefficient is greater than the preset behavior deviation threshold, it is determined that the safety node has abnormal behavior and the safety node is marked as a vehicle component threat behavior node. If the behavior deviation coefficient is less than or equal to the preset behavior deviation threshold, it is determined that the safety node does not have abnormal behavior.

[0010] As a further aspect of the present invention, a multi-dimensional security assessment index system is constructed based on the threat behavior nodes of vehicle components for comprehensive analysis to determine the security risk level of vehicle components, specifically as follows: By pre-setting weight coefficients for threat behavior nodes of vehicle components, a multi-dimensional security assessment model is constructed to calculate the security assessment factors of vehicle components. Based on the comparison between the security assessment factors and the pre-set security assessment range, the security risk level of the vehicle components is determined. Specifically: if the security assessment factor exceeds the upper limit of the pre-set security assessment range, it is at level one security risk; if the security assessment factor is within the pre-set security assessment range, it is at level two security risk; and if the security assessment factor is below the lower limit of the pre-set security assessment range, it is at level three security risk.

[0011] As a further aspect of the present invention, a hardware security architecture is built to trigger a security risk initiation process based on the security risk level of the vehicle components, thereby achieving security boot verification. The specific steps are as follows: The security risk level of the vehicle component is sent to the core control unit corresponding to the vehicle component. The core control unit uses the security risk level as a security status input parameter and passes it to the hardware security module. The hardware security module serves as the root of trust and uses a specified encryption verification algorithm to achieve secure boot verification.

[0012] As a further aspect of the present invention, a secure flashing process is designed, employing an asymmetric digital signature algorithm to ensure the authenticity and integrity of the software update package; a secure access control process is implemented to comply with the secure access service specifications of relevant industry standards.

[0013] An electronic device includes a memory and a processor, wherein the memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor performs the steps of the vehicle information security risk and threat protection assessment method described above.

[0014] The technical effects and advantages of this invention, a vehicle information security risk and threat protection assessment method and electronic device, are as follows: This invention clarifies the scope of vehicle information security risk and threat assessment and performs refined identification of security nodes and threat behavior nodes of vehicle components. This allows security assessment to move beyond the component or functional level and be refined to specific security behaviors and control nodes, thereby significantly improving the accuracy and targeting of risk identification and avoiding the omission of critical security vulnerabilities. Based on the threat behavior nodes of vehicle components, this invention constructs a multi-dimensional security assessment index system, quantitatively analyzing different threats in terms of severity, scope of impact, and occurrence characteristics. This determines the security risk level of vehicle components, transforming complex and multi-source security threat information into comparable and decision-making risk level results. This provides a unified and objective decision-making basis for the formulation of subsequent protection strategies, overcoming the subjectivity and lag problems caused by traditional reliance on manual experience or single-indicator judgments. This invention deeply couples security risk levels with hardware security architecture. Using a hardware security module as a root of trust, it triggers differentiated security risk startup processes based on different risk levels to achieve secure boot verification. Combined with secure flashing and secure access control processes, it provides end-to-end protection for software startup, upgrades, and diagnostic access. This risk-based startup and protection mechanism significantly enhances security in high-risk scenarios while avoiding unnecessary performance degradation in low-risk states, balancing system security and availability. Furthermore, this invention constructs a layered software architecture to achieve unified management, standardized forwarding, and efficient execution of security service requests. It employs an encrypted task publishing and notification mechanism to achieve efficient collaboration between the software layer and hardware security modules. Simultaneously, it incorporates the generation, storage, use, update, and destruction of security keys into a full lifecycle management system, effectively preventing key leakage, abuse, or loss of control, significantly improving the system's long-term security stability and maintainability.

[0015] This invention enables accurate identification, quantitative assessment, and tiered protection of vehicle information security risks, forming a unified security protection system covering the entire process of assessment, startup, operation, and maintenance. It improves the intelligence level, engineering feasibility, and overall anti-attack capability of vehicle information security protection, demonstrating significant technological advancement and practical application value. Attached Figure Description

[0016] Figure 1 This is a flowchart of a vehicle information security risk and threat protection assessment method provided in an embodiment of the present invention. Detailed Implementation

[0017] The technical solutions of this invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described technical solutions are only a part of this invention, and not all of it. All other technical solutions obtained by those skilled in the art based on the technical solutions of this invention without inventive effort are within the scope of protection of this invention.

[0018] like Figure 1 The diagram shown is a flowchart of a vehicle information security risk and threat protection assessment method provided by an embodiment of the present invention. Figure 1 The execution entity of the method shown can be a software and / or hardware device. The execution entity of this application can include, but is not limited to, at least one of the following: user equipment, network equipment, etc. User equipment can include, but is not limited to, computers, smartphones, personal digital assistants (PDAs), and the aforementioned electronic devices. Network equipment can include, but is not limited to, a single network server, a server group consisting of multiple network servers, or a cloud based on cloud computing consisting of a large number of computers or network servers. Cloud computing is a type of distributed computing, consisting of a super virtual computer composed of a group of loosely coupled computers. This embodiment does not limit this. Steps S1 to S4 are detailed as follows: Step S1: Based on the vehicle network security specifications, clarify the scope of vehicle information security risk and threat assessment, and identify vehicle component security nodes and vehicle component threat behavior nodes; In the process of building vehicle network security, this invention, based on vehicle network security specifications, first clearly defines the scope of the assessment of information security risks and threats to the entire vehicle. The assessment object is selected as the in-vehicle infotainment control unit, which involves human-machine interaction, external network communication, and multi-domain data interaction, and is a significant entry point into the vehicle's network attack surface. The assessment scope covers the hardware components, software components, and related interfaces of this control unit, and, in conjunction with the functional safety and network security requirements in the specifications, selects key nodes that have a significant impact on vehicle security as the focus of the assessment.

[0019] After defining the scope of the assessment, the corresponding security nodes for each in-vehicle infotainment control unit were identified. For example, at the hardware and software interaction level, the secure boot node responsible for verifying system boot integrity was identified; at the communication level, the identity authentication node responsible for authenticating external network access was identified; at the system operation level, the permission management node responsible for application permission allocation and resource access control was identified; and at the data processing level, the secure data access node responsible for reading and writing user privacy data was identified. These security nodes respectively undertake different security objectives such as integrity, confidentiality, permissions, and availability, and are the core functional units that ensure the safe operation of this vehicle component.

[0020] Based on this, and combined with the descriptions of typical attack scenarios and threat types in the vehicle network security specifications, potential threat behavior nodes at the aforementioned security nodes are identified. For example, at the secure boot node, threat behavior nodes such as unauthorized firmware replacement and boot chain tampering are identified; at the identity authentication node, threat behavior nodes such as brute-force attacks on weak passwords and unauthorized access by forged external device identities are identified; at the permission management node, threat behavior nodes such as unauthorized application permissions and unauthorized access to debugging interfaces are identified; and at the data access node, threat behavior nodes such as abnormal reading of user privacy data and unauthorized forwarding of cross-domain data are identified.

[0021] As can be seen from the above examples, this solution is based on vehicle network security specifications. It first clarifies the information security assessment boundaries of vehicle components, then refines the security nodes within the components, and further identifies the threat behavior nodes corresponding to the security nodes from a behavioral perspective. This lays a clear and operable foundation for subsequent differentiated security assessments, risk classifications, and the formulation of security protection strategies.

[0022] Step S2: Construct a multi-dimensional security assessment index system based on the threat behavior nodes of vehicle components for comprehensive analysis to determine the security risk level of vehicle components; After identifying security nodes and threat behavior nodes in the vehicle gateway control unit, this invention constructs a multi-dimensional security assessment index system based on the identified vehicle component threat behavior nodes. This system comprehensively analyzes the overall security status of the component. The multi-dimensional security assessment index system quantifies the threat behavior nodes from multiple dimensions such as threat severity, frequency of occurrence, scope of impact, and availability, so as to reflect the actual impact of different threats on the network security of the entire vehicle.

[0023] Specifically, within a certain assessment period, three main types of threat behavior nodes were identified in the vehicle gateway control unit: the first type is CAN bus abnormal message injection behavior nodes, which may directly affect cross-domain communication and the forwarding of critical control commands; the second type is diagnostic service privilege escalation behavior nodes, which may lead attackers to gain high-privilege access capabilities; and the third type is cross-domain data forwarding frequency abnormal behavior nodes, which may cause the risk of sensitive data leakage. For these different threat behavior nodes, different weight coefficients were set according to the security requirements for critical communication and control nodes in the vehicle network security specifications. Among them, the weight coefficient for CAN bus abnormal message injection behavior nodes was the highest, followed by diagnostic privilege escalation, and cross-domain data forwarding abnormality was relatively low.

[0024] When constructing a multi-dimensional security assessment model, the triggering status, duration, and degree of deviation of each threat behavior node within the assessment period are incorporated into the comprehensive calculation to generate a security assessment factor for the vehicle gateway control unit. Subsequently, this security assessment factor is compared and analyzed with a preset security assessment range: when the security assessment factor is significantly higher than the upper limit of the assessment range, the vehicle gateway control unit is determined to be at Level 1 security risk, indicating a high-risk threat that may directly impact the entire vehicle network; when the security assessment factor is within the assessment range, it is determined to be at Level 2 security risk, indicating a certain security risk but still under control; when the security assessment factor is lower than the lower limit of the assessment range, it is determined to be at Level 3 security risk, indicating that only low-risk or occasional threat behaviors exist.

[0025] This real-world example demonstrates that by quantifying threat behavior nodes and mapping them to a multi-dimensional security assessment indicator system, an objective assessment and classification of the safety status of vehicle components can be achieved. This provides a clear and actionable basis for subsequent differentiated security protection strategies and security startup procedures based on risk levels.

[0026] Step S3: By building a hardware security architecture, the security risk startup process is triggered based on the security risk level of the vehicle components to achieve secure boot verification. A secure flashing process and a secure access control process are designed to achieve software security protection. In the practical application of power domain security protection for intelligent connected vehicles, this invention identifies the power domain control unit (ECU) as a key component directly affecting vehicle driving and acceleration performance, thus placing it under priority for security management. First, based on a pre-defined multi-dimensional security assessment model, a comprehensive analysis is performed on the threatening behavior nodes identified by the ECU to determine its current security risk level. This risk level is then sent to the core control unit corresponding to the ECU. Upon vehicle power-on and startup, the core control unit transmits this risk level as a security status parameter to the hardware security module integrated within the chip. The hardware security module then acts as a trusted root, triggering a unified security risk initiation process.

[0027] When the power domain control unit is assessed as having a Level 1 safety risk, such as when a serious deviation from the integrity of the control algorithm firmware is detected, or when abnormal access to high-privilege diagnostics is detected, the hardware security module interrupts the normal startup process at the initial stage, prohibits application loading and execution, locks the firmware flashing interface and diagnostic access interface, and outputs a high-risk safety status flag to the core control unit. Based on this, the core control unit triggers a system reset or enters a restricted safety mode, retaining only basic drive protection logic to prevent abnormal control commands from affecting vehicle driving safety.

[0028] When the power domain control unit is at level two safety risk, the hardware security module allows it to enter a restricted boot state. In this state, the secure boot verification process is enhanced: the hardware security module not only performs authenticity and integrity verification on the bootloader, bootloader, and applications at each level, but also enables secondary verification or enhanced algorithms to verify critical control modules. Simultaneously, it restricts access to high-privilege diagnostic services and debugging interfaces, allowing only authorized maintenance equipment to perform limited operations, and continuously monitors the behavior of security nodes during operation. If the risk escalates, it can dynamically switch to a higher-level secure boot strategy.

[0029] When the power domain control unit is at a Level 3 safety risk level, the hardware safety module allows it to operate according to the standard safe startup procedure. Specifically, after the vehicle is powered on, the hardware safety module first verifies the signature and hash integrity of the bootloader. If the verification is successful, the boot manager is started. The boot manager then verifies the bootloader. If the verification is successful, the bootloader is loaded. Subsequently, the bootloader performs a final verification of the power control application. If the verification is successful, the application runs normally. If any stage of verification fails, a system reset is triggered or the system remains in the bootloader stage awaiting authorized diagnostic instructions, thereby ensuring the reliability of the entire startup chain.

[0030] During software updates and maintenance, a secure flashing process was designed for the power domain control unit. An asymmetric key pair is generated in a secure development environment, with the public key securely stored in the hardware security module. Before each firmware upgrade, the firmware to be flashed is hashed and digitally signed using the private key, generating a signed upgrade package. After the upgrade package is transmitted to the control unit via the diagnostic device, the bootloader calls the hardware security module to verify the signature. Firmware flashing is only allowed if verification is successful, preventing malicious or tampered firmware from being written into the power control system. Simultaneously, to prevent unauthorized devices from abusing diagnostic and control permissions, a secure access control process was designed for the power domain control unit. When an external diagnostic device requests access to high-privilege services, the core control unit generates a random seed through the hardware security module and sends it to the diagnostic device. The diagnostic device calculates the access key based on an agreed-upon algorithm, and the core control unit simultaneously calculates the verification key. The corresponding security level service is unlocked only if the two match; otherwise, the access request is rejected and abnormal behavior is recorded.

[0031] This invention uses a hardware security module as its core, integrating security risk levels, risk initiation processes, security boot verification, security flashing, and security access control into a unified design. This achieves hierarchical security protection throughout the entire process from startup and operation to maintenance, ensuring the safety and reliability of the power domain control unit in high-risk scenarios while also taking into account the availability and maintenance efficiency of vehicle components under normal operating conditions.

[0032] Step S4: Based on the layered software architecture, unified management, forwarding and execution of security service requests are realized. An encrypted task publishing and notification mechanism is adopted to achieve efficient collaboration with the hardware security module and realize full lifecycle management of security keys.

[0033] In this embodiment of the invention, the body domain control unit in the vehicle body domain control system is responsible for controlling the doors, windows, lights, and comfort functions. It also undertakes a large number of local communication and cross-domain data interaction tasks, placing high demands on the real-time performance and reliability of safety services. Therefore, in the software design of this body domain control unit, a layered safety software architecture is constructed based on an industry-standard safety software development framework to uniformly manage and schedule various safety service requests.

[0034] In this layered software architecture, the cryptography management module running on the main control core serves as a unified entry point, responsible for receiving security service requests from the operating system, middleware, and upper-layer applications, such as data encryption, message authentication, signature verification, and key usage requests. The cryptography management module categorizes security service requests based on request type and security policy, placing them into corresponding processing queues to achieve centralized management and priority control of these requests. Subsequently, the cryptography management module forwards specific encryption service requests to the cryptography interface module, which standardizes and encapsulates the requests, matching them with appropriate encryption algorithms and execution paths.

[0035] The cryptographic interface module further forwards the processed request to the cryptographic driver module. The cryptographic driver module, acting as a bridge between the software and hardware security modules, interacts with the hardware security module via inter-process communication or a dedicated bus. It abstracts and encapsulates the cryptographic primitives, key types, and security capabilities supported by the hardware security module, allowing upper-layer software to invoke hardware-level security capabilities without needing to be aware of the underlying hardware differences. This layered decoupling approach enables efficient forwarding and execution of security service requests from the application layer to the hardware layer.

[0036] In terms of operational mechanism, the vehicle body domain control unit is configured with a task publishing and notification mechanism for encryption tasks. For security operations with high timeliness requirements, a synchronous publishing method is adopted, where the main control core blocks and waits for the hardware security module to complete the calculation and return the result. For non-real-time tasks such as batch encryption and log signing, an asynchronous publishing method is adopted. After the hardware security module completes the encryption calculation, it notifies the main control core through interruption or polling, thereby avoiding the impact of security calculation on the main vehicle body control task and ensuring the real-time performance and stability of the overall operation. At the same time, the vehicle body domain control unit also implements full lifecycle management of security keys. During the vehicle production stage, the hardware security module generates and saves the root key and function key in its secure storage area. The password management module records the key generation time, purpose, security domain, and validity period through the key ledger. During vehicle operation, the key is only accessed in a controlled manner and is not exposed to the application layer in plaintext. When the software is upgraded or the function is changed, the key is updated or rotated according to the security policy. When the vehicle is scrapped or the control unit is retired, the hardware security module performs the key destruction operation and updates the key ledger record synchronously, ensuring that the key's entire lifecycle is traceable and controllable. By co-designing a layered software architecture and hardware security modules, unified management and efficient execution of security services are achieved. At the same time, the full lifecycle management of keys is incorporated into the system operation mechanism, effectively improving the overall information security protection capability of the vehicle body domain control unit in complex application scenarios.

[0037] Preferably, based on vehicle cybersecurity specifications, the scope of vehicle information security risk and threat assessment is defined, and vehicle component security nodes and vehicle component threat behavior nodes are identified. The specific steps are as follows: Based on the vehicle network security specifications, the scope of information security risk and threat assessment for vehicle components is clearly defined. Vehicle components include hardware components, software components and related interfaces, and the corresponding security nodes of vehicle components are identified. Based on capturing the corresponding security control attributes of each security node i This constitutes a set of security control attributes, among which, For the k-th security control attribute, Total number of security control attributes; Based on security control attributes, a expected behavior model is constructed for each security node to describe the allowed behavioral characteristics of the security node under normal conditions, serving as the first behavioral characteristic. ,in, For the set of allowed behavior types, The allowed execution time interval, For the allowed frequency range of behavior calls, The permitted permission level range; By collecting the actual behavioral characteristics of each node during the real-time operation of vehicle components, as the second behavioral characteristic... ,in, Characteristics of actual behavior types For the temporal characteristics of actual behavior, This is a characteristic of the frequency of actual behavior calls. Based on the actual permission level characteristics, a security behavior deviation coefficient analysis model is constructed according to the first behavior characteristic and the second behavior characteristic to obtain the behavior deviation coefficient corresponding to the security node. Abnormal behaviors of security nodes are identified based on behavioral deviation coefficients, and vehicle component threat behavior nodes are generated. A threat list is then established based on these vehicle component threat behavior nodes.

[0038] It should be noted that the security nodes corresponding to vehicle components include functional nodes for vehicle components to perform identity authentication, integrity verification, access control, and data access. Security control attributes include control objectives, control methods, triggering phases, target objects, and the range of allowed permission levels; control objectives include integrity, confidentiality, availability, and permissions; control methods include verification, authentication, authorization, and restriction; triggering phases include startup, flashing, running, and access; target objects include programs, data, interfaces, and storage areas.

[0039] In a specific embodiment of the present invention, the vehicle's power domain controller is used as the vehicle component to be evaluated. First, according to vehicle cybersecurity specifications, the power domain controller is identified as a core control component of the vehicle, involving a hardware microcontroller, boot firmware, application programs, and external diagnostic and flashing interfaces, thus falling within the scope of vehicle information security risk assessment. Further, security nodes within this vehicle component are identified, including authentication nodes during the boot phase, integrity verification nodes during the firmware loading phase, access control nodes during the runtime phase, and data access nodes during diagnostic communication.

[0040] For each of the aforementioned security nodes, corresponding security control attributes are extracted. For example, for an integrity verification node, its security control attributes include: control target is integrity, control method is verification, triggering phase is the boot and flashing phases, the target is the program storage area, and the allowed permission level is limited to bootloader calls only. Based on the set of security control attributes corresponding to each security node, an expected behavior model is constructed for each security node to describe its allowed behavior characteristics under normal conditions. For example, firmware verification behavior is limited to being triggered only during the boot phase, the call frequency is within a preset range, and it is only executed by modules with specific permission levels.

[0041] During actual vehicle operation, the operating status of the power domain controller is monitored in real time, and the actual behavioral characteristics of each safety node are collected. For example, during a vehicle startup, the actual behavior of the integrity verification node was collected as a program verification behavior, but its triggering sequence occurred during vehicle operation, and the call frequency was significantly higher than the frequency range allowed in the expected behavior model. At the same time, the module executing this behavior had its privilege level abnormally elevated. By comparing and analyzing the collected actual behavioral characteristics with the expected behavior model of the corresponding safety node, a safety behavior deviation coefficient analysis model is constructed. The calculated behavior deviation coefficient of this integrity verification node is significantly higher than the preset normal threshold.

[0042] Based on the behavioral deviation coefficient, the security node is determined to have abnormal behavior, and is marked as a threat behavior node of the vehicle component. The triggering stage, behavior type, and permission change characteristics involved in the abnormal behavior are further recorded to form a corresponding threat event entry. Subsequently, the threat behavior node is associated with the power domain controller and included in the vehicle component threat list for subsequent security risk assessment, risk level determination, and security protection strategy triggering, thereby achieving accurate identification and dynamic management of potential security threats to vehicle components.

[0043] Preferably, the calculation formula for the safety behavior deviation coefficient analysis model constructed based on the first behavioral characteristic and the second behavioral characteristic is as follows: ; In the formula: This is the behavioral deviation coefficient. This is a characteristic of the frequency of actual behavior calls. The number of types of the second behavioral characteristic. For the first The weight of the second behavioral feature of the class. For the first The second behavior of the class is a feature deviation function. For the first Class second behavioral characteristics, For the first The first behavioral characteristic of the class To determine the maximum allowed frequency of behavior calls, The minimum allowed frequency of behavior calls.

[0044] In this embodiment of the invention, under normal vehicle operation, the on-board gateway is responsible for authenticating, verifying permissions, and controlling access frequency for access requests from external diagnostic tools. Based on vehicle network security specifications, a first behavioral characteristic is established for this security node. The permitted behavior types include "diagnostic session establishment" and "status reading," with the permitted behavior execution sequence limited to a time window after vehicle ignition and while the vehicle is in maintenance or parking status; the permitted behavior call frequency range is, for example, no more than 5 diagnostic requests per minute; and the permitted permission level range is limited to read-only or restricted control permissions. This first behavioral characteristic serves as the expected behavior model of the security node under normal operating conditions.

[0045] During actual vehicle operation, the gateway's security monitoring module collects the node's secondary behavioral characteristics in real time. For example, within a certain time window, multiple instances of "diagnostic session reconstruction" and "flash requests" are detected, with the actual behavior call frequency reaching 12 times per minute, significantly exceeding the allowed maximum frequency of 5, accompanied by an attempt to escalate the permission level to engineering flash permissions. At this point, due to... The second case in the formula for calculating the behavior deviation coefficient is triggered. The deviation of behavior type, timing, frequency and permission are quantified by deviation function and then weighted and summed by the weight coefficients of various features to obtain the behavior deviation coefficient of the security node.

[0046] When the calculated behavior deviation coefficient exceeds the preset anomaly judgment threshold, the diagnostic access security node of the vehicle gateway is determined to have abnormal behavior, and it is marked as a threat behavior node of the vehicle component and recorded in the threat list. This threat list can then be used for overall vehicle security risk assessment, hardware security module to trigger access restrictions or enter a degraded operation mode, thereby realizing timely identification and protection against abnormal high-frequency diagnostic access or potential attack behavior in real vehicle operation scenarios.

[0047] Preferably, the abnormal behavior of security nodes is identified based on the behavior deviation coefficient, and vehicle component threat behavior nodes are generated. The specific steps are as follows: Extract the behavior deviation coefficient and compare it with the preset behavior deviation threshold. If the behavior deviation coefficient is greater than the preset behavior deviation threshold, it is determined that the safety node has abnormal behavior and the safety node is marked as a vehicle component threat behavior node. If the behavior deviation coefficient is less than or equal to the preset behavior deviation threshold, it is determined that the safety node does not have abnormal behavior.

[0048] In this embodiment of the invention, during normal vehicle operation, the on-board gateway continuously monitors the operational behavior of the diagnostic access security node. This security node is primarily responsible for authentication, permission verification, and access frequency control of external diagnostic requests. Its expected behavior has been modeled using a first behavioral feature. During actual operation, the security monitoring module periodically calculates the behavioral deviation coefficient corresponding to the security node based on the collected second behavioral features to quantify the degree of deviation of its actual behavior from the normal behavior model.

[0049] Within a certain monitoring period, the behavioral deviation coefficient of this safety node was extracted to be 0.78, while the behavioral deviation threshold set in advance based on vehicle network security specifications and historical operating data was 0.5. Because... If the actual behavior of the diagnostic access security node is determined to have significantly deviated from normal operation, it indicates an abnormal access risk. At this point, the security node is automatically marked as a vehicle component threat behavior node, and the corresponding node identifier, anomaly type (such as abnormal access frequency, permission overreach attempt), and anomaly occurrence time are recorded in the threat list, providing a basis for subsequent security risk assessment and coordinated protection.

[0050] Conversely, in routine vehicle maintenance scenarios, if the behavior deviation coefficient calculated for the same security node within the monitoring period is 0.32, which is less than or equal to the preset behavior deviation threshold of 0.5, then the behavior of the security node is determined to be within the normal range and there is no abnormal behavior. Therefore, it will not be included in the scope of vehicle component threat behavior nodes, thereby avoiding false alarms and ensuring the accuracy and stability of vehicle information security monitoring.

[0051] Furthermore, the abnormal behavior mentioned in this embodiment of the invention can specifically be as follows: Regarding the CAN interface threat behavior node at the hardware level, for the CAN communication interface between the emergency alarm host A and the vehicle's central control ECU, threat behavior nodes caused by unverified communication are identified. Under normal circumstances, this CAN interface is used to report the alarm status to the central control ECU and prompt the driver on the central control screen; however, when there is a lack of authentication and message integrity verification mechanisms, attackers can inject false alarm messages into the bus through the CAN interface, forming a "false alarm signal" threat behavior node, causing the driver to receive false alarm information on the central control screen, thereby misleading driving decisions. Simultaneously, attackers can also maliciously occupy the interface by continuously sending high-frequency or abnormal CAN messages, causing CAN interface blockage and forming an "interface availability disruption" threat behavior node, thus preventing the driver from receiving genuine alarm information in a timely manner.

[0052] Similarly, the same threat scenario exists in the CAN interface between the emergency alarm host A and the vehicle's central control ECU as in the emergency alarm host B. Because this CAN interface also lacks an effective communication verification mechanism, attackers can create corresponding threat behavior nodes by forging alarm signals or launching bus blocking attacks. This can cause the central control system to display false alarms or lose the availability of alarm information, potentially impacting vehicle operational safety. These threat behavior nodes are also included in the vehicle component threat behavior node list.

[0053] Secondly, regarding software-level threats related to program upgrade packages, high-risk threat behavior nodes related to the authenticity and integrity of upgrade packages were identified during the software upgrade process of the ESS host. In the absence of digital signatures and integrity verification mechanisms, attackers can send forged program upgrade packages to the host via the CAN interface, replacing or tampering with the original upgrade content, creating a threat behavior node where the "upgrade package authenticity is compromised." This can cause the host to run malicious or abnormal programs after the upgrade, severely impacting the core functions and system stability of the ESS host. Furthermore, attackers may also compromise the integrity of the program upgrade package by interfering with upgrade data transmission or tampering with parts of the upgrade content, leading to upgrade failure or abnormal system restarts, thus creating a threat behavior node where the "upgrade package integrity is compromised."

[0054] Preferably, a multi-dimensional security assessment index system is constructed based on the threat behavior nodes of vehicle components for comprehensive analysis to determine the security risk level of the vehicle components. Specifically, by pre-setting the weight coefficients of the threat behavior nodes of vehicle components, a multi-dimensional security assessment model is constructed to calculate the security assessment factor of the vehicle components. Based on the comparison between the security assessment factor and the pre-set security assessment range, the security risk level of the vehicle components is determined. Specifically, if the security assessment factor exceeds the upper limit of the pre-set security assessment range, it is at level one security risk; if the security assessment factor is within the pre-set security assessment range, it is at level two security risk; if the security assessment factor is below the lower limit of the pre-set security assessment range, it is at level three security risk.

[0055] In this embodiment of the invention, during vehicle operation, the safety monitoring system has identified multiple threatening behavior nodes related to the control unit based on the aforementioned behavioral deviation analysis. These include abnormal access nodes to the diagnostic interface, application permission overreach nodes, and abnormal data bus communication frequency nodes. For these threatening behavior nodes, a multi-dimensional safety assessment index system has been pre-constructed. The index dimensions include the degree of behavioral deviation, the scope of impact, the triggering frequency, and the level of potential safety consequences. Differentiated weight coefficients are configured for different types of threatening behavior nodes. For example, higher weights are assigned to abnormal data bus nodes that may affect vehicle control safety, while lower weights are assigned to abnormal application layer nodes that only affect information display functions.

[0056] Within a comprehensive assessment cycle, the behavioral deviation coefficients corresponding to each threat behavior node are weighted and calculated with their respective weight coefficients to obtain the security assessment factor of the control unit. Assuming the security assessment factor is 0.82, and the preset security assessment interval is... Since the safety assessment factor exceeds the upper limit of the preset safety assessment range of 0.7, the control unit is determined to be at the first level of safety risk and a high-risk handling strategy is triggered, such as restricting access to external interfaces, suspending non-essential application services, and reporting alarm information to the vehicle safety management module.

[0057] In another scenario, if the security assessment factor calculated based on threat behavior nodes is 0.55, it falls within the preset security assessment range. If the system determines that the control unit is at a Level 2 safety risk, it will only implement enhanced monitoring and logging strategies without affecting normal operation. However, if the safety assessment factor drops to 0.18, which is below the preset lower limit of 0.3, the vehicle component will be determined to be at a Level 3 safety risk, indicating that its overall safety status is good. Only routine safety monitoring will be maintained, thereby achieving refined classification assessment and differentiated control of vehicle component safety risks.

[0058] Preferably, the calculation formula for the multi-dimensional security assessment model is as follows: ; In the formula: Safety assessment factors for vehicle components. The weight coefficients for threat behavior nodes of vehicle components. The number of nodes exhibiting threat behaviors related to vehicle components. This is the threat behavior node for the a-th vehicle component.

[0059] In this embodiment of the invention, during vehicle operation, continuous security monitoring is performed on the on-board gateway control unit. Based on behavioral deviation analysis of security nodes, several threatening behavior nodes of vehicle components are identified, such as CAN bus abnormal message injection nodes, diagnostic session abnormal escalation nodes, and cross-domain data forwarding frequency abnormal nodes. Assume that A = 3 threatening behavior nodes are identified within a certain evaluation period, denoted as N1, N2, and N3. According to vehicle network security specifications and the degree of impact on overall vehicle safety, different weight coefficients are set for the above-mentioned threatening behavior nodes, where the weight coefficient for the CAN bus abnormal message injection node is set to 0.5, the weight coefficient for the diagnostic session abnormal escalation node is set to 0.3, and the weight coefficient for the cross-domain data forwarding frequency abnormal node is set to 0.2.

[0060] During this assessment period, each threat behavior node is quantified and assigned a value, where N1 = 1 (indicating that this type of high-risk abnormal behavior has been confirmed), N2 = 1 (abnormal diagnostic behavior exists), and N3 = 0 (no abnormality detected). Substituting these parameters into the calculation formula of the multi-dimensional security assessment model, the security assessment factor of the vehicle gateway control unit is obtained as follows: .

[0061] The calculated security assessment factors are then compared and analyzed with the preset security assessment interval. Assume the preset security assessment interval is... Since the safety assessment factor is 0.27, which is lower than the lower limit of the safety assessment range, the vehicle gateway control unit is determined to be at the level of Level 3 safety risk, indicating that the current overall security threat is controllable and only requires routine monitoring and periodic review. If a high-weight threat behavior node continues to appear in subsequent assessments, causing the safety assessment factor to exceed the upper limit of the safety assessment range, the risk level will be dynamically adjusted and the corresponding security protection and response procedures will be triggered, thereby realizing the quantitative assessment and hierarchical control of vehicle component safety risks.

[0062] Preferably, the specific steps for building a hardware security architecture are as follows: By integrating hardware security modules, we select hardware security modules that support functions such as security risk startup, calibration data integrity protection, sensor secure communication, and identity authentication. These modules are integrated with the microcontroller of the core control unit and serve as a trusted root for vehicle secure startup and various security verifications. Key encryption keys are generated within the hardware security modules and stored in their dedicated secure storage area to ensure that the keys are not illegally obtained. Configure a protection mechanism for the debugging interface. Securely configure the debugging interface during the vehicle production stage. Use a hash-based key generation algorithm to generate a high-strength access password. Combine this with the unique identification information from the hardware production process to generate a unique salt value. Implement an independent password mechanism for each hardware unit. Access to the debugging interface can only be obtained by entering the correct password, thus blocking illegal attacks launched through the debugging interface at the hardware level.

[0063] Preferably, by building a hardware security architecture, a security risk initiation process is triggered based on the security risk level of the vehicle components to achieve security boot verification. The specific steps are as follows: The security risk level of the vehicle component is sent to the core control unit corresponding to the vehicle component. The core control unit uses the security risk level as a security status input parameter and passes it to the hardware security module. The hardware security module is used as a trusted root and a specified encryption verification algorithm is used to implement secure boot verification. Specifically, after the vehicle is powered on, the hardware safety module triggers a safety risk startup process. When a vehicle component is at the first-level safety risk level, the hardware safety module triggers the first-level safety risk startup process, which includes: prohibiting the vehicle component from executing application startup; locking firmware flashing and diagnostic access permissions; outputting a high-risk safety status indicator to the core control unit; and triggering a system reset or entering a restricted safety mode.

[0064] When a vehicle component is at a level 2 security risk, the hardware security module triggers the level 2 security risk startup process. The level 2 security risk startup process includes: allowing the vehicle component to enter a restricted startup state; enabling enhanced security startup verification or secondary verification mechanisms; restricting access to some high-privilege diagnostic services and debugging interfaces; and continuously monitoring changes in the security status of the vehicle component.

[0065] When a vehicle component is at a Level 3 security risk level, the hardware security module triggers a Level 3 security risk startup process. The Level 3 security risk startup process includes: allowing the vehicle component to run according to the normal security startup process; maintaining basic security verification and access control policies; and not adding any additional security restrictions.

[0066] It should also be noted that the security risk initiation process also includes: when the vehicle components are at the level of Level 3 security risk, the authenticity and integrity of the boot program are verified through the hardware security module. If the verification is successful, the boot manager is run; if the verification fails, the system is reset. The boot manager then verifies the bootloader; if the verification passes, the bootloader is started; if the verification fails, the system is reset. The bootloader then verifies the application. If the verification passes, the application runs; otherwise, it remains in the bootloader state awaiting diagnostic instructions. This chain-like mechanism of progressive verification ensures the safety of vehicle components from startup to operation.

[0067] In this embodiment of the invention, during vehicle power-off restart or cold start, the vehicle safety management module first sends the safety risk level corresponding to the brake control unit to its corresponding core control unit based on the results of a prior safety risk threat assessment. The core control unit writes this safety risk level as a key safety status input parameter into the startup configuration area and simultaneously transmits it to the hardware security module integrated with the brake control unit. The hardware security module, acting as a trusted root, is activated upon vehicle power-on and is used to determine whether to trigger the safety risk startup process and the specific startup strategy employed.

[0068] When the assessment results indicate that the brake control unit is at a Level 1 safety risk level—for example, when a high-weight abnormal behavior node is detected in critical execution logic and the safety assessment factor significantly exceeds the upper limit of the safety range—the hardware security module triggers the Level 1 safety risk startup process at the initial startup stage. At this time, the hardware security module directly blocks the bootloader from jumping to the application program, prohibiting the brake control unit from executing the application startup; simultaneously, it locks the firmware flashing interface and diagnostic session interface through a hardware-level access control mechanism to prevent attackers from further tampering under high-risk conditions; and it outputs a high-risk safety status flag to the core control unit, which then triggers a system reset or puts the braking system into a restricted safety mode, retaining only basic mechanical braking redundancy functions to prevent the safety risk from spreading to the vehicle control layer.

[0069] When the braking control unit is assessed as a Level 2 safety risk (e.g., exhibiting moderate-weight anomalous behavior but not affecting critical control paths), the hardware security module triggers the Level 2 safety risk startup procedure. In this mode, the braking control unit is allowed to enter a restricted startup state, meaning that in addition to performing regular safety startup verification, enhanced safety startup verification or secondary integrity verification mechanisms are additionally enabled. Simultaneously, the hardware security module restricts access to certain high-privilege diagnostic services and debugging interfaces, allowing only read-only diagnostics or low-privilege service calls. During system operation, the hardware security module continuously monitors the behavioral characteristics of relevant security nodes, and immediately upgrades the startup strategy once an increase in risk level is detected.

[0070] When the brake control unit is at a Level 3 safety risk level, such as when only low-weight or occasional threat behavior nodes exist and the safety assessment factor is below the lower limit of the safety range, the hardware safety module does not trigger additional risk restrictions but allows it to operate according to the normal safe startup procedure. Specifically, after the vehicle is powered on, the hardware safety module first verifies the authenticity and integrity of the brake control unit's bootloader. If the verification is successful, the boot manager is started. The boot manager further verifies the bootloader; if the verification is successful, the bootloader is loaded; otherwise, a system reset is triggered. Subsequently, the bootloader performs a final verification of the brake control application. If the verification is successful, the brake control logic runs normally; if the verification fails, it remains in the bootloader state and waits for authorized diagnostic instructions. Through the above-mentioned chain-like safety mechanism of step-by-step verification, the safety and reliability of the brake control unit from startup to operation are ensured under low-risk conditions.

[0071] As can be seen from the embodiments of the present invention, by deeply coupling the safety risk assessment results with the hardware safety startup mechanism, differentiated startup control based on risk level is realized. This not only improves the safety protection strength of key vehicle components in high-risk scenarios, but also avoids introducing unnecessary performance loss in low-risk states, thus balancing vehicle safety and system availability.

[0072] Preferably, a secure flashing process and a secure access control process are designed to achieve software security protection. The specific steps are as follows: A secure flashing process is designed, employing an asymmetric digital signature algorithm to ensure the authenticity and integrity of the software update package. A pair of asymmetric public and private keys is generated in a secure development environment. The public key is stored in the secure storage area of ​​the hardware security module and managed by designated personnel. A hash value is calculated for the firmware to be updated using a hash algorithm. This hash value is then signed using the generated private key to obtain signature data, which is appended to the end of the original firmware to form a complete upgrade package. After the diagnostic device transmits the upgrade package to the storage area of ​​the core control unit, the bootloader calls the public key stored in the hardware security module to verify the signature of the upgrade package. Only after successful verification can the firmware flashing operation be completed.

[0073] The secure access control process is designed to comply with relevant industry standards for secure access services. After an authorized test device initiates a secure access request to unlock services at the corresponding security level, the core control unit generates a random seed using a true random number generation algorithm and sends it to the test device. The test device calculates the access key based on the received seed using a specified encryption algorithm, while the core control unit calculates the verification key using the same algorithm and seed. Upon receiving the access key from the test device, the core control unit compares the access key with the verification key. If they match, the target service is unlocked and a positive response is sent; otherwise, the access request is rejected and a negative response is sent, ensuring that only authorized devices can access sensitive data and related services.

[0074] Preferably, a layered software architecture is used to achieve unified management, forwarding, and execution of security service requests. An encrypted task publishing and notification mechanism is adopted to achieve efficient collaboration with the hardware security module. The specific steps are as follows: The software architecture is designed based on a specified security software development framework. The core control unit runs a cryptographic management module, a cryptographic interface module, and a cryptographic driver module that conform to industry standards. The cryptographic management module provides an interface for interaction with upper-layer modules and distributes security service requests to the corresponding processing queues. The cryptographic interface module forwards encryption service requests to the matching encryption driver. The cryptographic driver module acts as a bridge for communication with the hardware security module kernel, interacting with the hardware security module through inter-process communication mechanisms. It also provides an abstract encapsulation of the hardware security module's functions and clarifies the available cryptographic primitives and key information stored in the hardware security module.

[0075] The encryption task publishing and notification mechanism supports both synchronous and asynchronous publishing methods. After the encryption task is completed, the main core module is notified through polling or interruption mechanisms to ensure efficient scheduling and execution of encryption tasks and to ensure the smooth and coordinated operation of various security protection functions.

[0076] Preferably, the full lifecycle management of security keys is implemented, and the specific steps are as follows: Designate specific personnel to be responsible for the management of public and private keys, establish a key storage ledger, and record key data such as key generation time, version information, and scope of use in detail to ensure the traceability of the key throughout its entire lifecycle; When a project requires changes to the public or private key, the pre-defined departmental change management process must be strictly followed. A formal change application document must be submitted, and a dedicated decision-making committee will evaluate and make a decision. The key change operation can only be implemented after the approval is granted, ensuring the standardization and security of the key change process.

[0077] An electronic device includes a memory and a processor. The memory stores a computer program. When the processor runs the computer program stored in the memory, the processor executes the steps of the vehicle information security risk threat protection assessment method and electronic device described above. The electronic device includes: a processor, a memory, and a computer program; wherein... A memory is used to store the computer program, and the memory may also be flash memory. The computer program is, for example, an application program or functional module that implements the above method.

[0078] The processor is used to execute the computer program stored in the memory to implement the various steps performed by the device in the above method. For details, please refer to the relevant descriptions in the preceding method embodiments.

[0079] Alternatively, the memory can be either standalone or integrated with the processor.

[0080] When the memory is a device independent of the processor, the device may further include: A bus is used to connect the memory and the processor.

[0081] Through the above embodiments, this invention clarifies the scope of vehicle information security risk threat assessment and refines the identification of security nodes and threat behavior nodes of vehicle components. This allows security assessment to move beyond the component or functional level and delve into specific security behaviors and control nodes, significantly improving the accuracy and relevance of risk identification and preventing the omission of critical security vulnerabilities. Based on the threat behavior nodes of vehicle components, this invention constructs a multi-dimensional security assessment index system, quantitatively analyzing different threats in terms of severity, scope of impact, and occurrence characteristics. This determines the security risk level of vehicle components, transforming complex, multi-source security threat information into comparable and decision-making risk level results. This provides a unified and objective decision-making basis for subsequent protection strategy formulation, overcoming the subjectivity and lag issues of traditional reliance on manual experience or single-indicator judgments. This invention deeply couples security risk levels with hardware security architecture. Using a hardware security module as a root of trust, it triggers differentiated security risk startup processes based on different risk levels to achieve secure boot verification. Combined with secure flashing and secure access control processes, it provides end-to-end protection for software startup, upgrades, and diagnostic access. This risk-based startup and protection mechanism significantly enhances security in high-risk scenarios while avoiding unnecessary performance degradation in low-risk states, balancing system security and availability. Furthermore, this invention constructs a layered software architecture to achieve unified management, standardized forwarding, and efficient execution of security service requests. It employs an encrypted task publishing and notification mechanism to achieve efficient collaboration between the software layer and hardware security modules. Simultaneously, it incorporates the generation, storage, use, update, and destruction of security keys into a full lifecycle management system, effectively preventing key leakage, abuse, or loss of control, significantly improving the system's long-term security stability and maintainability.

[0082] This invention enables accurate identification, quantitative assessment, and tiered protection of vehicle information security risks, forming a unified security protection system covering the entire process of assessment, startup, operation, and maintenance. It improves the intelligence level, engineering feasibility, and overall anti-attack capability of vehicle information security protection, demonstrating significant technological advancement and practical application value.

[0083] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

[0084] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for assessing vehicle information security risks and threats, characterized in that, Includes the following steps: Based on vehicle network security specifications, the scope of vehicle information security risk and threat assessment is clearly defined, and vehicle component security nodes and vehicle component threat behavior nodes are identified. A multi-dimensional security assessment index system is constructed based on the threat behavior nodes of vehicle components for comprehensive analysis to determine the security risk level of vehicle components. By building a hardware security architecture, the security risk initiation process is triggered based on the security risk level of the vehicle components, thereby achieving secure boot verification. Furthermore, a secure flashing process and a secure access control process are designed to achieve software security protection. Based on a layered software architecture, it realizes unified management, forwarding and execution of security service requests, adopts an encrypted task publishing and notification mechanism, achieves efficient collaboration with hardware security modules, and realizes full lifecycle management of security keys.

2. The vehicle information security risk and threat protection assessment method according to claim 1, characterized in that, Based on the vehicle cybersecurity specifications, the scope of vehicle information security risk and threat assessment is clearly defined, and vehicle component security nodes and threat behavior nodes are identified. The specific steps are as follows: Based on the vehicle network security specifications, the scope of information security risk and threat assessment for vehicle components is clearly defined. Vehicle components include hardware components, software components and related interfaces, and the corresponding security nodes of vehicle components are identified. Based on the security control attributes captured for each security node i, a set of security control attributes is formed. A predictive behavior model is constructed for each security node based on security control attributes to describe the allowed behavior characteristics of the security node under normal conditions, serving as the first behavior characteristic. By collecting the actual behavioral characteristics of each node during the operation of vehicle components in real time, and using them as the second behavioral characteristics, a safety behavior deviation coefficient analysis model is constructed based on the first and second behavioral characteristics to obtain the behavioral deviation coefficients corresponding to the safety nodes. Abnormal behaviors of security nodes are identified based on behavioral deviation coefficients, and vehicle component threat behavior nodes are generated. A threat list is then established based on these vehicle component threat behavior nodes.

3. The vehicle information security risk threat protection assessment method according to claim 2, characterized in that, The set of security control attributes is ,in, For the k-th security control attribute, Total number of security control attributes; The first behavioral characteristic is ,in, For the set of allowed behavior types, The allowed execution time interval, For the allowed frequency range of behavior calls, The permitted permission level range; The second behavioral characteristic is ,in, Characteristics of actual behavior types For the temporal characteristics of actual behavior, This is a characteristic of the frequency of actual behavior calls. This refers to the actual level of access privileges.

4. The vehicle information security risk and threat protection assessment method according to claim 3, characterized in that, The security nodes corresponding to vehicle components include functional nodes for vehicle component authentication, integrity verification, access control, and data access.

5. The vehicle information security risk and threat protection assessment method according to claim 3, characterized in that, The calculation formula for the safety behavior deviation coefficient analysis model, based on the first and second behavioral characteristics, is as follows: ； In the formula: This is the behavioral deviation coefficient. This is a characteristic of the frequency of actual behavior calls. The number of types of the second behavioral characteristic. For the first The weight of the second behavioral feature of the class. For the first The second behavior of the class is a feature deviation function. For the first Class second behavioral characteristics, For the first The first behavioral characteristic of the class To determine the maximum allowed frequency of behavior calls, The minimum allowed frequency of behavior calls.

6. The vehicle information security risk and threat protection assessment method according to claim 3, characterized in that, The abnormal behavior of security nodes is identified based on the behavior deviation coefficient, and vehicle component threat behavior nodes are generated. The specific steps are as follows: Extract the behavior deviation coefficient and compare it with the preset behavior deviation threshold. If the behavior deviation coefficient is greater than the preset behavior deviation threshold, it is determined that the safety node has abnormal behavior and the safety node is marked as a vehicle component threat behavior node. If the behavior deviation coefficient is less than or equal to the preset behavior deviation threshold, the safe node is determined to have no abnormal behavior.

7. The vehicle information security risk and threat protection assessment method according to claim 1, characterized in that, Based on a multi-dimensional security assessment index system constructed from the threat behavior nodes of vehicle components, a comprehensive analysis is conducted to determine the security risk level of vehicle components, specifically: By pre-setting the weight coefficients of threat behavior nodes of vehicle components, a multi-dimensional security assessment model is constructed to calculate the security assessment factors of vehicle components. Based on the comparison between the security assessment factors and the pre-set security assessment interval, the security risk level of the vehicle components is determined. Specifically: if the safety assessment factor exceeds the upper limit of the preset safety assessment range, it is at the first level of safety risk. If the safety assessment factor is within the preset safety assessment range, it is at level two safety risk. If the safety assessment factor is lower than the lower limit of the preset safety assessment range, it is at level three safety risk.

8. The vehicle information security risk and threat protection assessment method according to claim 1, characterized in that, By building a hardware security architecture and outputting a security risk initiation process based on the security risk level of the vehicle components, security boot verification is achieved. The specific steps are as follows: The security risk level of the vehicle component is sent to the core control unit corresponding to the vehicle component. The core control unit uses the security risk level as a security status input parameter and passes it to the hardware security module. The hardware security module serves as the root of trust and uses a specified encryption verification algorithm to achieve secure boot verification.

9. The vehicle information security risk and threat protection assessment method according to claim 1, characterized in that, The software update package is designed with a secure write process and employs an asymmetric digital signature algorithm to ensure its authenticity and integrity. A secure access control process is also implemented to comply with relevant industry standards for secure access services.

10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor runs the computer program stored in the memory, the processor performs the steps of the vehicle information security risk threat protection assessment method as described in any one of claims 1-9.

Images