Method and apparatus for authority level-based security control of electronic equipment in multi-operating system environment in vehicle

Abstract

Disclosed are a method and an apparatus for authority level-based security control of electronic equipment in a multi-operating system environment in a vehicle. The apparatus for authority level-based security control of electronic equipment in a multi-operating system environment in a vehicle according to the present invention comprises: a vehicle computing device which simultaneously executes a first operating system and a second operating system executed independently of the first operating system; and a plurality of nodes connected to the vehicle computing device, wherein at least some of the plurality of nodes are activated in one of the first operating system and the second operating system and deactivated in the other operating system.

Description

Method and device for privilege-level-based security control of automotive electronic equipment in a multi-operating system environment within a vehicle

[0001] The present invention relates to a method and apparatus for security control of electronic equipment in a multi-operating system environment within a vehicle, and more particularly to a technology that restricts command execution according to the privilege level and role of electronic equipment and enhances the cybersecurity of a vehicle through physical and logical separation between a high-security operating system and a low-security operating system.

[0002] The automotive industry is currently facing a new paradigm due to the advancement of connected cars. Connected cars provide various services and functions through communication between internal vehicle systems and external networks, significantly contributing to the enhancement of vehicle convenience and safety. However, this increased connectivity is further highlighting the importance of cybersecurity and Firmware Over-The-Air (FOTA) updates.

[0003] Compliance with UNECE R155 (Cybersecurity Management System) and UNECE R156 (Software Update Management System) standards is becoming mandatory, particularly in Europe and the United States. These standards require vehicle manufacturers to protect vehicles from cybersecurity threats and provide safe and efficient software updates.

[0004] Traditionally, vehicles used CAN bus-based internal communication networks, which limited external connectivity, resulting in relatively few security issues. However, connected cars operate multiple operating systems via hypervisors and perform data communication with external servers, increasing the likelihood of security vulnerabilities. Generally, operating systems are divided into high-security operating systems for vehicle control and low-security operating systems responsible for infotainment; the interaction between these operating systems is a critical consideration from a security standpoint.

[0005] The prior art, U.S. Patent US12079354 "Computing device and data transmission method," proposes a data encryption transmission method to address security issues arising during data transmission between a high-security operating system and a low-security operating system. This technology aims to mitigate security vulnerabilities by having the two operating systems run within the same computer via a hypervisor, and by separating roles and functions based on the security level of each operating system.

[0006] However, these conventional technologies alone are insufficient to completely prevent attempts to hack a vehicle by installing aftermarket electronic components instead of genuine parts after the vehicle has been delivered. The possibility still exists of infiltrating the vehicle system through hardware devices by exploiting security vulnerabilities in low-security operating systems. For example, there is a risk that a high-security operating system and critical vehicle systems can be accessed by hacking a low-security operating system through the connection of a third-party device to the vehicle.

[0007] The present invention aims to resolve the problems of the prior art described above by providing a methodology that limits the types of commands and security levels that can be requested according to the roles and authority of electronic equipment in a multi-operating system environment within a vehicle, and strengthens security at the hardware level through physical and logical separation between a high-security operating system and a low-security operating system.

[0008] A security control device for electronic equipment based on privilege levels in a multi-operating system environment within a vehicle according to the present invention comprises: a first operating system; a second operating system that runs independently of the first operating system; a vehicle computing device that simultaneously runs the first operating system; and a plurality of nodes connected to the vehicle computing device.

[0009] At this time, if at least some of the above multiple nodes are activated in either the first operating system or the second operating system, they are deactivated in the other one.

[0010] The above vehicle computing device includes an authority level table for the plurality of nodes, wherein the authority level table includes one of network configuration information, an activated operating system value, a role, and an authority level for at least some of the nodes among the plurality of nodes.

[0011] When one node is activated in one operating system and deactivated in the other, this is stored and reflected in the aforementioned authority level table.

[0012] Meanwhile, when the vehicle computing device receives a request from any one node, the vehicle computing device queries the authority level table to determine whether to process or reject the request.

[0013] Meanwhile, the vehicle computing device executes a hacking response routine when a request from any one of the nodes exceeds the privilege level or role of the corresponding node.

[0014] According to the present invention, security vulnerabilities can be minimized by restricting command execution according to the privilege level and role of electronic equipment in a multi-operating system environment within a vehicle, and furthermore, cyber attacks at the hardware and software levels can be effectively defended against through physical and logical separation between a high-security operating system and a low-security operating system.

[0015] This enables compliance with UNECE R155 and R156 standards and satisfies international cybersecurity standards, thereby enhancing the safety and reliability of connected cars.

[0016] Figure 1 is an example of a vehicle computer implementation, and

[0017] FIG. 2 is a diagram illustrating the hardware structure of a privilege level-based electronic equipment security control device in a multi-operating system environment within a vehicle according to the present invention.

[0018] FIG. 3 is a diagram illustrating the software layer of a privilege level-based electronic equipment security control device in a multi-operating system environment within a vehicle according to the present invention, and

[0019] Figure 4 is a diagram illustrating an authority level table, and

[0020] Figure 5 is a flowchart that chronologically explains a security control method for electronic equipment based on privilege levels in a multi-operating system environment within a vehicle according to the present invention.

[0021] Explanation of the symbols

[0022] 100 : Automotive computing device

[0023] 101 : Processor

[0024] 102 : Storage device

[0025] 103 : Communication adapter

[0026] 110 : Electrical equipment

[0027] 1000: Hypervisor

[0028] 1001: First Operating System

[0029] 1002: Second Operating System

[0030] 1003 : Privilege Level Table

[0031] 1010 : Node

[0032] Hereinafter, the present invention will be described in detail with reference to preferred embodiments of the invention and the accompanying drawings, under the premise that identical reference numerals in the drawings refer to identical components.

[0033] When a component is described as "comprising" another component in the detailed description of the invention or the claims, this shall not be interpreted as being limited to being composed solely of said component unless specifically stated otherwise, but shall be understood as potentially including additional components.

[0034] Additionally, components named as "~means," "~part," "~module," or "~block" in the detailed description of the invention or the claims refer to units that process at least one function or operation, and each of these may be implemented by software or hardware, or a combination thereof.

[0035]

[0036] Hereinafter, an example of the implementation of the app linkage cluster, the control system, and the method thereof according to the present invention will be described through specific embodiments.

[0037] Figure 1 is an example of a vehicle computer implementation.

[0038] Automotive computers are generally developed as hardware that constitutes the vehicle's cluster screen and are installed in the vehicle. They act as a network gateway, relaying communication between internal and external networks and managing various systems of the vehicle in an integrated manner.

[0039] Recent connected cars simultaneously operate a high-security operating system for vehicle control and a low-security operating system responsible for infotainment, and are implemented as a hypervisor.

[0040] A hypervisor is software that enables multiple operating systems to run simultaneously on a single physical computer resource. It virtualizes physical hardware resources to make it appear as though each operating system (virtual machine) uses the hardware independently. Generally, Type 1 hypervisors, also known as bare metal hypervisors, are used in connected cars. They feature a structure where they are installed directly on top of physical hardware to virtualize operating systems. In other words, the hypervisor runs at the lowest layer of the system to manage multiple operating systems simultaneously.

[0041] Hypervisors are often implemented on the hardware resources of a vehicle computer as exemplified in FIG. 1, and embodiments of the present invention are described below based on this premise.

[0042] Figure 2 is a diagram illustrating the hardware structure of a privilege level-based electronic equipment security control device in a multi-operating system environment within a vehicle according to the present invention.

[0043] As illustrated in FIG. 2, the vehicle computing device (100) is equipped with a processor (101), a storage device (102), and a communication adapter (103). The vehicle computing device (100) is connected to a plurality of electronic devices (110) within the vehicle.

[0044] The processor (101) is the central processing unit of the vehicle computing device (100) and performs various computation and control functions.

[0045] The storage device (102) is a non-volatile storage device that stores an operating system, applications, a privilege level table (1003), etc. It may be non-volatile memory or an SSD or other storage device.

[0046] The communication adapter (103) is an interface device responsible for communication with the electrical device (110) inside the vehicle and with an external network, and supports communication by known wired or wireless communication protocols.

[0047] FIG. 3 is a diagram illustrating the software layer of a privilege level-based electronic equipment security control device in a multi-operating system environment within a vehicle according to the present invention.

[0048] The hypervisor (1000) runs on the processor (101) and simultaneously runs the first operating system (1001) and the second operating system (1002). It supports a multi-operating system environment and is responsible for the partitioning and management of hardware resources.

[0049] The first operating system (1001) performs various functions to ensure the safety and security of the vehicle. The first operating system (1001) is a high-security operating system related to vehicle control and includes the following functions.

[0050] First, it performs the function of controlling the braking system. It optimizes the vehicle's braking performance and supports safe driving through driving safety systems such as braking force management, ABS (Absorbent Brake-force Control), and ESC (Electronic Stability Control).

[0051] In addition, it includes engine control and powertrain management functions. It regulates engine performance and fuel efficiency through the Engine Control Unit (ECU), and optimizes the vehicle's driving condition by collecting and monitoring powertrain-related data in real time.

[0052] Next, it performs the function of controlling the airbag system. When a collision is detected, it immediately deploys the airbag to ensure the safety of the vehicle's occupants. At the same time, it controls the electronic power steering (EPS) and suspension systems to maintain the vehicle's driving stability and handling performance.

[0053] The vehicle security system is also one of the main functions controlled by the first operating system (1001). It manages door locking and unlocking, immobilizers, vehicle intrusion detection systems, etc., to prevent unauthorized access to the vehicle and enhance vehicle security.

[0054] It also integrates and controls ADAS (Advanced Driver Assistance System) functions. Through features such as Lane Keeping Assist, Forward Collision Warning, and Automatic Emergency Braking (AEB), it enhances driving safety and supports accident prevention.

[0055] On the other hand, the second operating system (1002) is a low-security operating system that provides infotainment and user convenience features. An operating system such as Android Automotive OS or QNX (BlackBerry QNX) can be used as the second operating system (1002) to facilitate the installation and execution of applications.

[0056] The second operating system (1002) is an operating system designed to provide in-vehicle infotainment systems and user convenience functions, and primarily provides various multimedia and connectivity services such as navigation, music streaming, voice recognition, and smartphone integration. To provide these functions, the second operating system is connected to various external networks and devices to perform data communication, and for this purpose, it provides various communication interfaces such as Bluetooth, Wi-Fi, and USB ports.

[0057] Due to this connectivity, the second operating system (1002) is relatively easy to access from the outside, and unlike the first operating system, it performs functions unrelated to the vehicle's core safety functions, so security settings and access control management are inevitably limited. In particular, if third-party aftermarket electronic devices are installed in the vehicle, there is a possibility that the second operating system will be connected to these devices, which increases the risk of security vulnerabilities occurring.

[0058] The method of hacking the second operating system (1002) through a third-party aftermarket electronic device and the resulting risks are as follows.

[0059] Aftermarket electronic devices are components developed and sold by external manufacturers rather than being genuine parts from the vehicle manufacturer; they include various types such as navigation systems, audio systems, and interior lighting controllers. These devices can be connected to the vehicle's secondary operating system to exchange control or data, and if these devices have weak security or are equipped with malicious software, the secondary operating system can be utilized as a gateway for hacking.

[0060] Hackers can attack a secondary operating system (OSS) via aftermarket electronic devices in the following manner. First, they connect a third-party device to the vehicle via USB or Wi-Fi, and then attempt unauthorized access by exploiting security vulnerabilities in the secondary OSS through malicious software. For instance, they can infiltrate the system by accessing the secondary OSS's file system or intercepting network communication packets. If such an attack is successful, the hacker can exploit the secondary OSS to attempt access to the primary OSS or other critical vehicle systems through the vehicle's network.

[0061] Such security vulnerabilities not only threaten the cybersecurity of the vehicle but also pose a risk that hackers may collect or manipulate the vehicle's driving data through the vehicle's infotainment system. Additionally, attempts may occur to intercept communication with the first operating system (1001) or to control the hardware resources used by the first operating system (1001) after taking control of the second operating system (1002) through a third-party device. This can cause problems that directly affect safety by transmitting unwanted commands or tampering with data regarding the vehicle's core functions.

[0062] Therefore, since the second operating system (1002) must actively support connectivity and data communication with external devices due to its characteristics, it is inevitably relatively vulnerable to security compared to a high-security operating system, and there may be security vulnerabilities associated with the installation of third-party aftermarket electronic devices.

[0063] To prevent this, the vehicle computing device (100) according to the present invention utilizes an authority level table (1003). The authority level table (1003) is a database stored in a storage device (102) and includes information such as network configuration information, activated operating system values, roles, and authority levels of each node (1010).

[0064] The first operating system (1001) and the second operating system (1002) are designed to share some data to manage various electronic devices (110) and network configuration information within the vehicle. At this time, the first operating system (1001) is a high-security operating system that performs functions directly related to the safety of the vehicle, while the second operating system (1002) is a low-security operating system that provides infotainment and user convenience functions and is responsible for connecting with the vehicle's multimedia system and external devices. In this structure, the two operating systems are physically and logically separated, but some data, such as the authorization level table (1003), is shared to maintain consistency in the vehicle system and ensure safe and efficient function execution.

[0065] The authorization level table (1003) includes information such as network configuration information, activated operating system, role, and authorization level of each electronic device (110), thereby providing basic data for overall system management and access control of the vehicle. This table can be accessed by both the first operating system (1001) and the second operating system (1002), but access rights for each operating system are set differently to enhance security.

[0066] The first operating system (1001) has read and write permissions for the authority level table (1003). This is necessary to enhance the security of the vehicle and maintain the stability of the system. Since the first operating system (1001) controls the core safety functions of the vehicle, it must be able to modify data within the authority level table (1003) in real time to grant or restrict permissions depending on the situation. For example, it must be able to perform functions such as adjusting the authority level of a specific electronic device (110) or reflecting the addition of a new electronic device in the authority level table.

[0067] On the other hand, the second operating system (1002) has only read-only access to the authorization level table (1003). This is because the second operating system is an operating system that primarily provides infotainment and user convenience functions, and may be relatively vulnerable in terms of security. The second operating system exchanges data through connections with external networks and third-party devices, and there is a possibility that security vulnerabilities may occur due to this connectivity. If the second operating system is hacked, the authorization level table (1003), which is set to read-only, cannot be tampered with, and this plays an important role in blocking the overall security risks of the system.

[0068] Therefore, the first operating system (1001) and the second operating system (1002) share the authority level table (1003), but the first operating system exclusively has the modification authority, thereby minimizing the possibility of system tampering and hacking attempts due to security vulnerabilities in the second operating system.

[0069] A node (1010) is a concept representing various electronic devices (110) within a vehicle from a software perspective, and is connected to a hypervisor (1000) via a network to manage and communicate the status and data of each electronic device. The node (1010) tracks the roles and status of the electronic devices and supports interaction with each operating system in the vehicle's multi-operating system environment through the hypervisor.

[0070] However, the term "node" is not limited solely to a software concept but is also used at the physical level of a network, referring to physical resources within the actual network infrastructure. For example, physical electronic devices on a network, such as switches, sensors, and cameras, are all represented as nodes, and these devices maintain their own unique network addresses and connection states.

[0071] Accordingly, the term node (1010) is used to encompass multiple electronic devices (110) within the vehicle, and this can be understood as a concept that reflects the connectivity between the vehicle's network infrastructure and electronic devices in both software and physical terms.

[0072] Hereinafter, embodiments of the present invention will be examined.

[0073] Hereinafter, embodiments of the present invention will be described in detail. An authority level-based electronic equipment security control device in a multi-operating system environment within a vehicle according to the present invention comprises a first operating system (1001), a vehicle computing device (100) that simultaneously executes a second operating system (1002) that executes independently of the first operating system (1001), and a plurality of nodes (1010) connected to the vehicle computing device (100).

[0074] The first operating system (1001) is a high-security operating system that controls the safety-critical functions of the vehicle, and the second operating system (1002) is a low-security operating system that provides infotainment and user convenience functions. In this structure, the two operating systems each run independently and enhance security by maintaining physical and logical separation through a hypervisor (1000).

[0075] At least some of the multiple nodes (1010) connected to the vehicle computing device (100) are designed to be disabled in the remaining operating systems when they are enabled in a specific operating system.

[0076] For example, if a specific node (1010) is activated in the first operating system (1001), the node is deactivated in the second operating system (1002), and conversely, if it is activated in the second operating system (1002), it is deactivated in the first operating system (1001).

[0077] This structure is controlled through the authority level table (1003), minimizing interference between each operating system and maintaining security.

[0078] Network configuration information may include various information for identifying nodes of a network, such as MAC addresses or IP addresses. This information indicates how multiple electronic devices (110) in the vehicle are connected to the vehicle computing device (100) and is used to uniquely identify each node (1010) on the network.

[0079] The active operating system value is a value indicating whether the node (1010) is active in the first operating system (1001) or the second operating system (1002), and can be set to a flag value such as '1' or '2', for example. This value serves to identify whether the node is currently active in the high-security operating system (1001) or in the low-security operating system (1002).

[0080] Roles are classified into driveline, braking, camera, light, etc., depending on the function performed by the node (1010). Accessible security levels may be set differentially according to each role. For example, as shown in FIG. 4, the role of indoor lighting is defined as light, and in this case, the authority level is set to 5. This means that the indoor lighting device has the lowest authority level, and the authority allowed is limited according to its role.

[0081] In this way, the authority level table (1003) determines the maximum authority that can be requested from the operating system according to the role of each node. The higher the authority level, the greater the authority to perform requests related to the safety or security of the vehicle, and this is granted to nodes related to critical system control of the vehicle. For example, a node such as a brake system unit has the highest authority level and is configured to perform critical requests related to the braking of the vehicle.

[0082] Through this authority level table (1003), the security level of each node (1010) is efficiently managed, and based on this, the vehicle's operating system can make a decision to allow or deny requests.

[0083] For example, the brake system unit (110) has a braking role and its authority level is set to 1. The brake system unit (110) monitors important data related to the vehicle's braking status in real time and, accordingly, can perform requests requiring high authority to the high-security operating system (1001). These requests include important functions such as, for example, the execution of an emergency braking command, the activation of the ABS (ABS) and ESC (Electronic Stability Control), and the adjustment of braking force distribution.

[0084] When a request is made from the brake system unit (110), the vehicle computing device (100) refers to the authority level table (1003) to review the authority level of the request and the role of the node. The authority level table (1003) includes network configuration information, activated operating system values, roles, and authority level information of the node (1010), and through this, the legality and security of each request are determined.

[0085] To explain this in detail, it is as follows.

[0086] First, when an emergency braking command request is received from the brake system unit (110), the vehicle computing device (100) queries the authority level table (1003) to confirm that the authority level of the corresponding node (1010) is set to '1'. Authority level '1' signifies the highest authority, which grants the authority to perform functions directly related to the safety of the vehicle. Accordingly, the vehicle computing device (100) approves this request and executes the emergency braking command through the first operating system (1001).

[0087] On the other hand, for example, the interior lighting unit (110) has the role of light and is set to a privilege level of 5. When a request for a system setting change is received from the interior lighting unit (110), the vehicle computing device (100) queries the privilege level table (1003) to confirm that the privilege level of the corresponding node (1010) is '5'. A privilege level of '5' signifies a low security level, which grants the authority to perform functions that are not directly related to the safety of the vehicle. Therefore, the vehicle computing device (100) approves this request, but processes the request only within a limited scope through the second operating system (1002).

[0088] Additionally, the vehicle computing device (100) maintains security between operating systems by continuously updating the authority level table (1003) whenever a request from each node (1010) occurs in real time. For example, if the first operating system (1001) adds a new high-security node or adjusts the authority level of an existing node, this is immediately reflected in the authority level table (1003), thereby strengthening the security policy of the entire system.

[0089] In particular, the present invention prevents changes to the authority level caused by hacking attempts on the second operating system (1002) by restricting the access rights of the authority level table (1003) to be writable only by the first operating system (1001). For example, even if the second operating system (1002) is hacked and attempts to access the authority level table (1003), access is restricted to read-only access, so the authority level cannot be changed. This is an important security mechanism that prevents attacks exploiting security vulnerabilities of the second operating system (1002) from affecting the core safety functions of the first operating system (1001) and the vehicle.

[0090] In addition, the present invention provides a system that dynamically manages permissions based on a permission level table (1003). For example, when a vehicle is in a collision state, the first operating system (1001) temporarily raises the permission levels of all nodes (1010) through the permission level table (1003) to enable a rapid response to an emergency situation. This dynamic permission management function maximizes the safety of the vehicle and enables the application of flexible security policies in various driving situations.

[0091] In addition, the present invention adopts an encrypted storage and transmission method to ensure the data integrity of the privilege level table (1003). All privilege level information is stored in an encrypted form in the storage device (102), and is transmitted using an encrypted protocol even when exchanging data between operating systems. Through this, unauthorized access to the privilege level table (1003) or attempts to tamper with the data can be effectively prevented.

[0092] As seen above, the nodes (1010) are configured to make requests or communicate with only one of the first operating system (1001) or the second operating system (1002) at a specific time. This structure is essential for maintaining independence and security between operating systems and serves to minimize the risk of security breaches.

[0093] However, in certain situations, a high-security operating system (1001) and a low-security operating system (1002) may need to exchange control authority over the vehicle's electronic equipment (110). For example, consider a situation where the vehicle switches from autonomous driving mode to manual driving mode.

[0094] In autonomous driving mode, the first operating system (1001) fully controls safety-critical devices such as the vehicle's core systems, such as the brake system, power steering, and accelerator control. At this time, the second operating system (1002) focuses primarily on infotainment and user interfaces, providing information to the driver such as route guidance or music playback. However, when switching to manual driving mode, the second operating system (1002) also needs to temporarily control or access some of the vehicle's data, such as brake or engine data. In such cases, the first operating system (1001) must temporarily grant specific authority to the second operating system (1002) to share necessary data or transfer control authority.

[0095] Another example is when the infotainment device in a system installed in a vehicle malfunctions or requires a reboot under certain circumstances. In such situations, the first operating system (1001) may need to temporarily replace or control some basic functions of the infotainment system until the second operating system (1002) is reactivated. In this case, the first operating system (1001) is configured to temporarily perform the role of the second operating system (1002) using the authority level table (1003), and then returns to its original state after the infotainment system is restored.

[0096] Additionally, when an emergency situation occurs due to the vehicle facing a collision, the second operating system (1002) is responsible for collecting various sensor data (e.g., camera, radar, LiDAR) of the vehicle and visually displaying it to the driver. At this time, the first operating system (1001) must immediately activate the vehicle's control system to execute safety-critical commands, but at the same time, it may need to refer to the visual information provided by the second operating system (1002). In such cases, the first operating system (1001) may temporarily receive specific data access rights from the second operating system (1002) to process it.

[0097] The second operating system (1002) is designed so that it cannot modify the authority level table (1003) on its own. This is a measure to protect the integrity of the authority level table (1003) from external attacks or hacking attempts that exploit security vulnerabilities of the second operating system (1002). Therefore, when the second operating system (1002) requires a specific authority change, it sends an authority change request to the high-security first operating system (1001).

[0098] When the first operating system (1001) receives the request, it queries the authorization level table (1003) to review the legitimacy of the request and determines whether to approve it. For example, if the vehicle's driving mode changes or a specific emergency situation occurs and the second operating system (1002) needs to temporarily access or control high-security data, the first operating system (1001) may review the request and grant approval.

[0099] When the request is approved, the first operating system (1001) modifies the authority level table (1003) to temporarily change the active operating system value of the corresponding node (1010) and reset the associated authority level. In this process, the first operating system (1001) stores the new authority value and operating system state in the authority level table (1003), and this is immediately reflected in other electronic devices (110) or nodes (1010) of the vehicle.

[0100] In this way, when the activated operating system is in a modified state, the authority of the corresponding node (1010) is temporarily modified, and additional access authority is granted to perform specific functions. For example, when the second operating system (1002) needs to temporarily read data from the first operating system (1001) or needs to change the setting value of a specific electronic device (110), the first operating system (1001) accepts such a request and raises the authority. Afterward, when the requested operation is completed, the first operating system (1001) restores the authority level table (1003) to its original state and returns the access authority of the second operating system (1002) to a restricted state.

[0101] Through this, the second operating system (1002) cannot change its authority on its own, but when necessary, it can temporarily receive authority through the first operating system (1001) to perform specific functions.

[0102] By operating the authority level table (1003) in this manner, first, the authority level table (1003) provides a structure that can centrally manage detailed access rights for multiple nodes (1010) within the vehicle. By including information such as network configuration information, activated operating system values, roles, and authority levels of each node, it becomes possible to grant subdivided authority according to the functions performed by the various electronic devices (110) of the vehicle.

[0103] In addition, access control through an authority level table prevents the transfer of security threats by ensuring exclusive operation between electronic devices. For example, by ensuring that electronic devices running on a high-security operating system (1001) do not share direct authority with electronic devices running on a low-security operating system (1002), it is possible to effectively block vulnerabilities of the low-security operating system from spreading to the high-security operating system. This provides an important security mechanism that strengthens the physical and logical separation between electronic devices, thereby protecting the core functions of the vehicle in security breach scenarios.

[0104] Next, access control based on privilege level tables significantly enhances the system's scalability and flexibility. When the vehicle's electronic devices increase or new functions are added, new nodes can be easily registered in the privilege level table, and the roles and permissions of each node can be adjusted. This is more efficient than the existing exclusive operation method and facilitates easy changes or updates to security policies. Furthermore, the ability to change permissions in real time provides the flexibility to respond rapidly to changes in the vehicle's operating status or environment.

[0105] Finally, access control through the privilege level table enables rapid response and recovery in the event of a security incident. The information recorded in the privilege level table provides a basis for monitoring the security status of the vehicle in real time and immediately detecting and responding to abnormal access attempts. For example, if the second operating system (1002) is hacked and attempts to access the privilege level table, the attempt to change the privilege fails because the privilege level table is set to read-only, which allows the vehicle's core system to be protected from external attacks.

[0106] Furthermore, access control based on privilege level tables facilitates compliance with vehicle cybersecurity standards. To comply with international security standards such as UNECE R155 and R156, all electronic devices within a vehicle must operate under clear security policies. Privilege level tables provide a means to systematically implement the detailed access control policies necessary to meet these standards.

[0107] The vehicle computing device (100) described above may reject a request from any one of the nodes (1010) if the request exceeds the authority level or role of the node, as described above, and furthermore, may execute a hacking response routine. Since hacking can be carried out in various forms, such as unauthorized access attempts by external attackers, insertion of malicious software, or modification of network communication, the implementation of an effective response mechanism is essential. Accordingly, the present invention provides a comprehensive hacking response routine for the vehicle computing device (100) to detect hacking attempts and to quickly track and respond to them.

[0108] First, the detection of hacking attempts is achieved through a multi-stage security verification process. The vehicle computing device (100) verifies the validity of all received requests in real time by referring to an authority level table (1003). In this process, if a request exceeds the authority level or does not meet the role, additional security verification procedures are activated beyond simply rejecting the request. These procedures include an anomaly detection algorithm to identify abnormal request patterns, machine learning-based behavioral analysis, and real-time log monitoring.

[0109] Tracking hacking is achieved by comprehensively analyzing various log data and network traffic data collected in real time by a vehicle computing device (100). To this end, the present invention introduces a distributed log system based on blockchain technology to store all request and response logs in an immutable form. This system records the metadata of the request on the blockchain network whenever a request occurs from each node (1010), thereby enabling accurate tracking of the timing of the hacking attempt and reliable identification of its source. Furthermore, by utilizing machine learning algorithms to analyze log data in real time and detecting abnormal signs early, rapid response is possible.

[0110] It monitors internal and external security conditions and automatically performs response measures when abnormal signs are detected. For example, an AI algorithm analyzes abnormal traffic patterns from a specific node (1010), automatically blocks access to that node, and sends an immediate alert to the administrator. This automated response system minimizes the timing of hacking attempts.

[0111] Meanwhile, some electronic devices (110) require swapping the authority level or the active operating system, while others electronic devices (110) operate fixed to a specific operating system and do not require switching operating systems. In such cases, when connecting electronic equipment to a vehicle computing device (100), electronic equipment for the first operating system (1001) and electronic equipment for the second operating system (1002) can be distinguished, and dedicated connection ports suitable for each operating system can be provided.

[0112] Since this hardware structure allows for the physical separation and control of which operating system each battlefield device is connected to and activated, the values ​​within the privilege level table (1003) remain fixed, thereby enhancing the security of the battlefield device by eliminating the need for swapping privileges or operating systems. In other words, since the ports of each battlefield device are fixedly connected, it becomes impossible to change privileges due to system configuration changes or hacking attempts. For example, a battlefield device connected to the first operating system (1001) is designed so that it cannot be physically switched to the second operating system (1002), thereby preventing tampering with the system even through physical access.

[0113] In addition, the vehicle computing device (100) may additionally be equipped with physical setting devices such as DIP switches or jumpers to physically fix the activation status and authority level of each electronic device. By using DIP switches or jumpers, the role and authority level of each electronic device can be set at the hardware level, thereby allowing the electronic device to maintain a certain security state despite any software setting changes.

[0114] For example, if a specific sensor performs a safety-critical function such as vehicle collision detection, the authority level of the sensor can be fixed using a DIP switch so that it is connected only to the first operating system (1001). When configured in this way, the activation status and authority level of the sensor are physically fixed and cannot be changed by software access or hacking attempts. This serves as an important security mechanism that allows the high-security operating system to reliably use the data of the electronic device, especially when the vehicle is exposed to an accident or external attack.

[0115] Figure 5 is a flowchart that chronologically explains a security control method for electronic equipment based on privilege levels in a multi-operating system environment within a vehicle according to the present invention.

[0116] The present invention illustrated in FIG. 5 is executed in a vehicle computing device (100) connected to a plurality of nodes (1010).

[0117] First, the vehicle computing device (100) receives a request from a specific node (1010). The request is transmitted to a communication adapter (103) via a network and to a first operating system (1001) and a second operating system (1002) via a hypervisor (1000).

[0118] When a request is received, the first operating system (1001) queries the authority level table (1003) and verifies the suitability of the request based on the network configuration information, active operating system value, role, authority level, etc. of the node that performed the request (S1).

[0119] The first operating system (1001) examines whether a request exceeds the authority of the corresponding node (1010) defined in the authority level table (1003) or is consistent with the role of the corresponding node. For example, if a specific node has a control authority set to '3', but attempts to execute a request requiring a '1' level authority, it is determined to be an excess request.

[0120] If the request does not exceed the authority level or is not unsuitable for the role, the first operating system (1001) approves the request and proceeds to the next step. Otherwise, the request is immediately rejected and recorded in the log (S2).

[0121] When the request is approved, the first operating system (1001) prepares a temporary authority change to the required authority level for the corresponding node (1010). To do this, the authority level table (1003) is temporarily modified to raise the authority of the corresponding node or change the active operating system value.

[0122] In this process, the first operating system (1001) stores the original authority level information as separate backup data so that it can be restored to its original state after the work is completed (S3).

[0123] The first operating system (1001) updates the authority level table (1003) to temporarily change the authority level of the node and then transmits the authority to the second operating system (1002) so that the requested operation can be performed.

[0124] The requested work is executed according to the changed authority, for example, a specific node may work with the first operating system (1001) to temporarily modify data directly related to the safety of the vehicle or to change system settings (S4).

[0125] When the requested task is completed, the first operating system (1001) checks the status of the node (1010) and the task results. After reviewing whether the task was successfully completed and whether no errors occurred, it prepares to restore the authority (S5).

[0126] The first operating system (1001) restores the authority level table (1003) to its original state based on the backup data saved in the S3 step. At this time, not only the authority level but also the active operating system value of the node is restored to its initial value so that the system can operate normally.

[0127] After recovery is complete, the first operating system (1001) updates the authority level table (1003) to ensure that the status of all nodes has returned to a normal state (S6).

[0128]

[0129] The technical concept of the present invention has been examined through the above examples.

[0130] It is obvious that a person skilled in the art to which the present invention pertains can make various modifications or changes to the embodiments described above from the description of the present invention. Furthermore, it is obvious that a person skilled in the art to which the present invention pertains can make various modifications including the technical concept according to the present invention from the description of the present invention, even if not explicitly illustrated or described, and such modifications still fall within the scope of the rights of the present invention. The embodiments described above with reference to the accompanying drawings are described for the purpose of explaining the present invention, and the scope of the rights of the present invention is not limited to these embodiments.

Claims

1. A vehicle computing device that simultaneously executes a first operating system; a second operating system that executes independently of the first operating system; and a plurality of nodes connected to the vehicle computing device; wherein A security control device for electronic equipment based on privilege levels in a multi-operating system environment within a vehicle, characterized in that at least some of the aforementioned multiple nodes are activated in either the first operating system or the second operating system and are deactivated in the other.

2. In Paragraph 1, The above vehicle computing device includes an authority level table for the plurality of nodes, wherein the authority level table includes one of network configuration information, an activated operating system value, a role, and an authority level for at least some of the nodes among the plurality of nodes. A security control device for electronic equipment based on privilege levels in a multi-operating system environment within a vehicle, characterized in that when there is a request from any one node, the vehicle computing device queries the privilege level table to determine whether to process or reject the request.

3. In Paragraph 2, A security control device for electronic equipment based on privilege levels in a multi-operating system environment within a vehicle, characterized in that the above-mentioned vehicle computing device executes a hacking response routine when a request from any one of the above-mentioned nodes exceeds the privilege level or role of the corresponding node.

Images