Vehicle-mounted hardware safety management method

Abstract

The invention relates to a vehicle-mounted hardware security management method. An isolation sandbox, a resource abstraction module, a dynamic resource scheduling module and a security policy engine are arranged between a vehicle-mounted application and vehicle-mounted hardware; the resource abstraction module uniformly takes over a vehicle-mounted hardware interface and presets a permission template of a vehicle-mounted application at the same time, and the security policy engine allocates sandbox instances of different security levels according to the type of the vehicle-mounted application and loads the preset permission template of the vehicle-mounted application to obtain a security policy library; the vehicle-mounted application applies for accessing the hardware resources through the isolation sandbox and the resource abstraction module, and the dynamic resource scheduling module performs permission decision on the vehicle-mounted hardware in combination with the current vehicle state and the security policy library. According to the method and the system, the ways of accessing the vehicle-mounted hardware by the vehicle-mounted application illegally bypassing the system behavior are reduced, the human input is saved, and the stability and the safety of the system are improved at the same time.

Description

Technical Field

[0001] The present invention relates to a vehicle-mounted hardware security management method, and belongs to the technical field of vehicle-mounted applications. Background Art

[0002] In today's era of rapid technological advancement, intelligent, connected vehicles have become a core trend in the transformation of the global automotive industry. With the deep integration and widespread application of cutting-edge technologies such as artificial intelligence, 5G communications, and big data, intelligent, connected vehicles have not only dramatically changed people's travel patterns but also reshaped the functional positioning of automobiles, gradually evolving from simple means of transportation to mobile smart terminals that integrate intelligent driving, information exchange, entertainment, and leisure. In particular, when it comes to in-car entertainment systems, consumers are no longer satisfied with simple functions such as traditional radios and CD players. Instead, they seek the stunning visual experience provided by large, high-definition displays, a full range of entertainment content including online music, videos, and games, and intelligent interactive experiences, transforming the in-car space into a true mobile entertainment and leisure destination.

[0003] However, a deeper analysis of the current technological implementation of in-vehicle systems reveals numerous pressing issues. From the perspective of in-vehicle hardware operation and management, with the increasing diversity of in-vehicle applications, in-vehicle hardware such as cameras, radars, CAN (Controller Area Network), and displays must support the concurrent operation of multiple applications. However, the security levels and permission requirements of different applications vary significantly, posing serious security risks. For example, malicious applications could exploit vulnerabilities in system permission management to gain unauthorized access to hardware resources, maliciously access cameras to obtain private information inside or outside the vehicle, or illegally manipulate radar systems to interfere with the vehicle's normal sensing functions, seriously threatening the vehicle's safe operation and the privacy of users.

[0004] A review of traditional in-vehicle security solutions and operating systems reveals significant limitations in access control. Most lack fine-grained access control mechanisms, making it impossible to accurately allocate and manage application permissions based on the dynamic changes in different application scenarios. While the vehicle is in motion, when the autonomous driving system requires sensors such as cameras and radar to perceive road conditions, traditional systems struggle to flexibly adjust application access permissions to these hardware resources based on the complexity of real-time road conditions and the varying levels of driving automation. In some special scenarios, such as navigating complex road construction or inclement weather, the autonomous driving system's access permissions to hardware resources cannot be promptly enhanced to ensure more accurate and comprehensive environmental information, thus impacting the accuracy and timeliness of driving decisions. Furthermore, when the vehicle is stationary and only the in-vehicle entertainment system is in use, unnecessary access to critical hardware resources by entertainment applications cannot be effectively restricted, leading to potential security risks.

[0005] Furthermore, the management model for in-vehicle hardware resources is relatively fragmented. Individual hardware devices are often independently managed by different subsystems, lacking a unified, efficient security management strategy. This results in extremely low protection efficiency for the entire in-vehicle system against security threats. When potentially malicious behavior is detected in an application, the lack of a unified management mechanism prevents the security protection functions of various hardware devices from being quickly and coordinated, resulting in high response latency. Malicious applications can damage hardware resources or steal illegal data before the system can effectively respond, severely impacting the normal operation of the vehicle and the security of user data. If these issues are not properly addressed, they will become bottlenecks hindering the further development of intelligent connected vehicles. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide a unified and efficient vehicle-mounted hardware security management method.

[0007] In order to solve the above technical problems, the technical solution proposed in the present invention is: a vehicle-mounted hardware security management method, which is provided with an isolation sandbox, a resource abstraction module, a dynamic resource scheduling module and a security policy engine between the vehicle-mounted application and the vehicle-mounted hardware; During the initialization phase, the resource abstraction module takes over the vehicle hardware interface and presets the permission template for vehicle applications, rejecting any behavior that does not access the hardware through the resource abstraction module. When an in-vehicle application is started, the security policy engine allocates sandbox instances of different security levels according to the type of the in-vehicle application, and loads the preset permission template of the in-vehicle application to obtain a security policy library; The in-vehicle application applies for access to hardware resources through the resource abstraction module, and the dynamic resource scheduling module makes permission decisions for the in-vehicle hardware in combination with the current vehicle status and the security policy library.

[0008] The present invention applies sandbox isolation technology and introduces a resource abstraction module between the sandbox and the vehicle-mounted hardware. Therefore, the vehicle software does not need to be updated for the addition or update of hardware. The resource abstraction module manages the vehicle-mounted hardware in a unified manner, restricting the behavior of vehicle-mounted applications accessing the vehicle-mounted hardware only through the sandbox and the resource abstraction module, reducing the ways for vehicle-mounted applications to illegally bypass the system to access the vehicle-mounted hardware, saving manpower investment while increasing the stability and security of the system.

[0009] The beneficial effects brought about by the present invention are as follows: 1) This invention shields hardware differences through a resource abstraction module, achieving unified permission management across vehicle models / platforms. By combining a sandbox with the resource abstraction module, the method for in-vehicle applications to access in-vehicle hardware is restricted to this system, thus tightening the access path to in-vehicle hardware.

[0010] 2) The present invention automatically adjusts sandbox permissions based on the vehicle status (such as driving mode), so that the vehicle has a high level of application security protection in different states.

[0011] 3) The security policy engine in the present invention directly drives the resource scheduling module, and policy changes take effect in real time, reducing protection delays. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 It is a schematic diagram of the principle of an embodiment of the present invention.

[0013] Figure 2 It is a flowchart of an embodiment of the present invention.

[0014] Figure 3 It is a workflow diagram of the monitoring module.

[0015] Figure 4 This is a processing diagram after adding hardware. DETAILED DESCRIPTION

[0016] This embodiment shows a method for vehicle hardware security management. Figure 1 and Figure 2 As shown, an isolation sandbox, resource abstraction module, dynamic resource scheduling module, and security policy engine are deployed between in-vehicle applications and in-vehicle hardware. The isolation sandbox creates an independent sandbox environment for each in-vehicle application, restricting its direct access to hardware resources. The resource abstraction module abstracts in-vehicle hardware (such as sensors, GPUs, and cameras) into standardized interfaces for applications within the sandbox. The dynamic resource scheduling module dynamically allocates and determines the hardware resource access permissions that in-vehicle applications can request based on the security level of the in-vehicle application and the current vehicle status (such as driving / parked). The security policy engine integrates a security policy library (such as process whitelists and abnormal behavior models) to generate and distribute security policies in real time.

[0017] During the initialization phase, the resource abstraction module takes over unified vehicle hardware interfaces. Preferably, it abstracts the vehicle hardware into standardized interfaces. For example, cameras and radars can be packaged into unified abstract classes, and driver adaptation for different hardware vendors can be achieved through dynamic link libraries (DLLs). A permission template for vehicle applications is also preset to deny any hardware access that is not approved by the resource abstraction module.

[0018] When an in-vehicle application is launched, the security policy engine assigns sandbox instances of different security levels based on the type of in-vehicle application and loads the preset in-vehicle application permission template to generate a security policy library. For example, when a user launches an in-vehicle gaming application while the vehicle is parked, the security policy engine, based on the "parked" state template, will allow the gaming application to access entertainment hardware such as the GPU and display, while blocking any access requests to control hardware such as the steering wheel and brakes, as part of the security policy library.

[0019] The in-vehicle application applies for access to hardware resources through the resource abstraction module. The dynamic resource scheduling module makes permission decisions for the in-vehicle hardware based on the current vehicle status and security policy library. For example, when the vehicle enters a school area (triggered by GPS), the system automatically downgrades the camera access rights of the entertainment application from "full permission" to "only video stream resolution ≤ 360P" and increases the radar data sampling frequency of the ADAS system to 10Hz (normally 5Hz).

[0020] In this embodiment, the resource abstraction module uniformly manages the vehicle-mounted hardware, restricting the behavior of vehicle-mounted applications to access the vehicle-mounted hardware only through the sandbox and resource abstraction module, reducing the ways for vehicle-mounted applications to illegally bypass the system to access the vehicle-mounted hardware, saving manpower investment while increasing the stability and security of the system.

[0021] Preferably, Figure 3 As shown, this embodiment may further include a monitoring module, which detects the behavior of the in-vehicle application in real time and immediately triggers abnormal isolation or resource recovery operations if an abnormality is found.

[0022] Because the resource abstraction module is introduced in this embodiment, the vehicle software does not need to be updated for the addition or update of hardware. Figure 4 shown.

[0023] The following example illustrates security management during the installation of a third-party in-car app: 1) A user attempts to install an in-car entertainment app. The system automatically creates a sandbox instance for it, with initial permissions set to "access only the display and audio output." 2) When the app requests access to the GPS module, the security policy engine detects that it is not a navigation app, denies the request, and logs it. 3) If the app repeatedly attempts to access the camera, the monitoring module marks it as a high-risk application, triggering the sandbox to be destroyed and notifying the installer to uninstall the app.

[0024] Let's take real-time protection during driving as an example: When the vehicle enters autonomous driving mode, the dynamic resource scheduling module adaptively adjusts safety policies, prohibiting non-ADAS applications from accessing intelligent driving sensors such as cameras, lidar, and millimeter-wave radar. It also dynamically limits the entertainment system's CPU usage to no more than 10%, and prohibits application scheduling during non-driving conditions, such as over-the-air (OTA). If the monitoring module detects that an in-vehicle application's sandbox resources have exceeded their limits due to a memory leak, it immediately releases the sandbox and restarts the in-vehicle application process.

[0025] This embodiment can also be improved as follows: the security policy engine supports dynamic policy updates. Preferably, the security policy engine remotely loads new policies to the security policy engine via OTA, such as receiving policy packages from a cloud security center through an OTA channel, and adopting differential update technology similar to Android System Update.

[0026] The present invention realizes fine-grained permission control of vehicle-mounted hardware resources, real-time threat protection of vehicle-mounted applications and cross-platform compatibility through sandbox isolation, dynamic resource scheduling and a unified policy engine.

Claims

1. A vehicle-mounted hardware security management method, characterized by: An isolation sandbox, resource abstraction module, dynamic resource scheduling module, and security policy engine are set up between the in-vehicle application and the in-vehicle hardware; During the initialization phase, the resource abstraction module takes over the vehicle hardware interface and presets the permission template for vehicle applications, rejecting any behavior that does not access the hardware through the resource abstraction module. When an in-vehicle application is started, the security policy engine allocates sandbox instances of different security levels according to the type of the in-vehicle application, and loads the preset permission template of the in-vehicle application to obtain a security policy library; The in-vehicle application applies for access to hardware resources through the isolation sandbox and resource abstraction module, and the dynamic resource scheduling module makes permission decisions for the in-vehicle hardware in combination with the current vehicle status and the security policy library.

2. The vehicle-mounted hardware security management method according to claim 1, characterized in that: It also includes a monitoring module, which detects the behavior of in-vehicle applications in real time. If an abnormality is found, it immediately triggers abnormal isolation or resource recovery operations.

3. The vehicle-mounted hardware security management method according to claim 1, characterized in that: The security policy engine supports dynamic policy updates.

4. The vehicle-mounted hardware security management method according to claim 3, characterized in that: The security policy engine remotely loads new policies to the security policy engine via OTA.

5. The vehicle-mounted hardware security management method according to claim 1, characterized in that: The resource abstraction module abstracts the vehicle hardware into a standardized interface.

Images