Vehicle-mounted information processing device, information processing method, and program

Abstract

To provide an on-vehicle information processing device, an information processing method, and a program, which can monitor access operation to data by applications on the basis of simple rules.SOLUTION: The on-vehicle information processing device comprises: a determination section 101 that determines whether or not target data, which is data that first applications are attempting to access, is permitted data on the basis of a correspondence relation list specifying correspondence relations between each of the first applications 30 and permitted data which is data the respective first applications have been permitted to access; and access control sections 102 and 104 that permit the first applications to access the target data when the determination section determines that the target data is the permitted data, and do not permit the first applications to access the target data when the determination section determines that the target data is not the permitted data.SELECTED DRAWING: Figure 3

Description

[Technical field]

[0001] The present invention relates to an in-vehicle information processing device, an information processing method, and a program. [Background technology]

[0002] The following Patent Document 1 discloses an information processing device that disables an application process if it is determined that the process is an attack based on rules that define what processes (behaviors) of an application (program) are attacks against a CPU. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] JP 2019-8503 A Summary of the Invention [Problem to be solved by the invention]

[0004] Various applications may be installed in the in-vehicle information processing device. For example, an application created by a third party, which is an organization different from the vehicle manufacturer that manufactured the vehicle in which the in-vehicle information processing device is installed, may be installed in the in-vehicle information processing device. In this case, there is a risk that the application may illegally access data recorded in the in-vehicle information processing device. In other words, there is a risk that the application may attack the in-vehicle information processing device.

[0005] In order to determine whether or not an attack occurs for all processes of an application in the above Patent Document 1, the above rule needs to be made complex. Therefore, when the technical idea of ​​the above Patent Document 1 is applied to an in-vehicle information processing device, the computation load on the in-vehicle information processing device becomes large. Therefore, it is necessary to build the in-vehicle information processing device using an expensive hardware configuration.

[0006] In consideration of the above, an object of the present invention is to provide an in-vehicle information processing device, an information processing method, and a program capable of monitoring an application's access to data based on simple rules. [Means for solving the problem]

[0007] The in-vehicle information processing device described in claim 1 is an in-vehicle information processing device installed with a hypervisor, a first operation system and a second operation system that operate independently of each other on the hypervisor, and at least one first application that operates on the first operation system, and includes: a first recording unit in which multiple types of data that the first application can access via the hypervisor and the second operation system are recorded; a second recording unit in which a correspondence list that specifies a correspondence between each of the first applications and permission data, which is the data that each of the first applications is permitted to access, is recorded; a judgment unit that judges whether or not target data, which is the data that the first application is attempting to access, is the permission data based on the correspondence list; and an access control unit that permits the first application to access the target data when the judgment unit determines that the target data is the permission data, and does not permit the first application to access the target data when the judgment unit determines that the target data is not the permission data.

[0008] The in-vehicle information processing device according to claim 1 has a first recording unit in which a plurality of types of data that at least one first application running on a first operation system can access via a hypervisor and a second operation system is recorded. The in-vehicle information processing device further has a second recording unit in which a correspondence list that defines a correspondence between each first application and permission data that is data that each first application is permitted to access is recorded. Furthermore, a determination unit determines whether or not target data that is data that the first application is attempting to access is permission data based on the correspondence list. Furthermore, when the determination unit determines that the target data is permission data, an access control unit permits the first application to access the target data.

[0009] In this way, the access operation of the first application to data is monitored based on the rules that indicate the correspondence between each first application and the permission data defined by the correspondence list. Furthermore, the rules that define the correspondence between each first application and the permission data are simpler than rules that define all the processes (behavior) of all the first applications. Therefore, in the in-vehicle information processing device according to claim 1, the access operation of the first application to data can be monitored based on simple rules. Therefore, the computation load on the in-vehicle information processing device is not large. Therefore, there is no need to build the in-vehicle information processing device using an expensive hardware configuration.

[0010] The in-vehicle information processing device of the invention described in claim 2 is the invention described in claim 1, wherein the first middleware operating on the first operation system realizes at least one API (Application Programmable Interface), each of the first applications operates on the first middleware, the correspondence list specifies a correspondence between each of the first applications and an authorized API that is the API to which each of the first applications is permitted to access and that can be accessed by each of the first applications to obtain the authorized data, and the determination unit determines whether the target API is the authorized API based on the correspondence list when it determines that the first application has accessed a target API that is at least one of the APIs, and the access control unit is a first access control unit realized by the first middleware that permits the first application determined by the first determination unit to have accessed the authorized API to access the second operation system via the first operation system and the hypervisor.

[0011] In the invention described in claim 2, a first middleware operating on a first operation system realizes at least one API, and each first application operates on the first middleware. The system further includes a first determination unit realized by the first middleware, which determines whether or not a target API is an authorized API based on the correspondence list when the determination unit determines that the first application has accessed a target API which is at least one API. The system further includes a first access control unit realized by the first middleware, which allows the first application determined by the first determination unit to have accessed the authorized API to access a second operation system via the first operation system and the hypervisor.

[0012] In this way, the access operation of the first application to data is monitored based on the rules that indicate the correspondence between each first application and the authorized API, as specified by the correspondence list. The rules that specify the correspondence between each first application and the authorized API are simpler than the rules that define all the processes of all the first applications. Therefore, the invention described in claim 2 can monitor the access operation of the first application to data based on the simple rules.

[0013] The in-vehicle information processing device of the invention described in claim 3 is the invention described in claim 2, wherein a second middleware operating on the second operation system realizes at least one of the APIs, and the judgment unit is provided with a second judgment unit realized by the second middleware that determines whether the target API accessed by the first application determined by the first judgment unit to have accessed the permitted API is the permitted API based on the correspondence list, and the access control unit is provided with a second access control unit realized by the second middleware that allows the first application to access the permitted data when the second judgment unit determines that the target API is the permitted API.

[0014] In the invention described in claim 3, a second middleware running on a second operation system realizes at least one API. The determination unit further includes a second determination unit realized by the second middleware that determines whether a target API accessed by a first application determined by the first determination unit to have accessed an authorized API is an authorized API based on the correspondence list. The access control unit further includes a second access control unit realized by the second middleware that permits the first application to access the authorized data when the second determination unit determines that the target API is an authorized API.

[0015] In this way, the access operation of the first application to data is monitored based on the rules that indicate the correspondence between each first application and the authorized API, as specified by the correspondence list. The rules that specify the correspondence between each first application and the authorized API are simpler than the rules that define all the processes of all the first applications. Therefore, the invention described in claim 3 can monitor the access operation of the first application to data based on the simple rules.

[0016] Furthermore, in the in-vehicle information processing device of claim 3, a second determination unit realized by a second middleware determines whether or not a target API accessed by a first application determined by a first determination unit realized by a first middleware to have accessed an authorized API is an authorized API based on the correspondence list. In this way, access to the data (first recording unit) of the first application is monitored twice, so that it is possible to determine with higher accuracy whether or not a target API accessed by the first application is an authorized API.

[0017] The in-vehicle information processing device of the invention described in claim 4 is the invention described in claim 3, and is further provided with a third recording unit in which a frequency list specifying frequency conditions which are conditions regarding the frequency of access by the first application to the permission API is recorded, and when the second determination unit determines that the frequency of access by the first application to the permission API does not satisfy the frequency condition, the second access control unit does not allow the first application to access the permission data.

[0018] The in-vehicle information processing device of the invention described in claim 4 includes a third recording unit in which a frequency list that specifies a frequency condition that is a condition regarding the frequency of access by the first application to the authorized API is recorded. Furthermore, when the second determination unit determines that the frequency of access by the first application to the authorized API does not satisfy the frequency condition, the second access control unit does not permit the first application to access the authorized data. The rule regarding this frequency condition is simpler than a rule that defines all processes of all first applications. Therefore, the invention described in claim 4 can monitor the access operation of the first application to data based on a simple rule.

[0019] The in-vehicle information processing device of the invention described in claim 5, in the invention described in claim 3 or claim 4, is provided with an abnormality processing unit realized by the second middleware, which uninstalls the first application that has accessed the target API that is determined by the second determination unit to be not the permitted API from the in-vehicle information processing device.

[0020] An access by the first application to a target API that is determined by the second determination unit to be not an authorized API is considered to be a high-risk process. That is, such a first application may perform a high-risk attack on the in-vehicle information processing device. In the invention described in claim 5, the abnormality processing unit uninstalls the first application that has accessed the target API that is determined by the second determination unit to be not an authorized API from the in-vehicle information processing device. Therefore, the invention described in claim 5 makes it possible to protect the in-vehicle information processing device from the first application that may perform a high-risk attack.

[0021] The in-vehicle information processing device of the invention described in claim 6 is an invention described in any one of claims 3 to 5, wherein the data recorded in the first recording unit is data acquired by at least one second application operating on a third operation system that operates independently of the first operation system and the second operation system on the hypervisor.

[0022] In the invention as recited in claim 6, the access operation of a first application to data acquired by at least one second application running on a third operation system can be monitored based on a simple rule.

[0023] The in-vehicle information processing device of the invention described in claim 7 is the invention described in claim 6, in which at least one of the second applications acquires data regarding physical quantities that change in conjunction with at least one of the driving, steering, and braking of the vehicle in which the in-vehicle information processing device is installed.

[0024] In the invention described in claim 7, the access operation of the first application to the data related to the physical quantity that changes in conjunction with at least one of the running, steering, and braking of the vehicle equipped with the in-vehicle information processing device can be monitored based on a simple rule. Therefore, the first application that may attack the in-vehicle information processing device is less likely to illegally obtain such data.

[0025] The information processing method described in claim 8 is an information processing method performed by an in-vehicle information processing device in which a hypervisor, a first operation system and a second operation system operating independently of each other on the hypervisor, and at least one first application operating on the first operation system are installed, and includes the steps of: when the first application attempts to access a recording unit in which multiple types of data are recorded via the hypervisor and the second operation system, determining whether or not target data, which is the data that the first application is attempting to access, is the permitted data based on a correspondence list that specifies a correspondence between the first application and permitted data, which is the data that each of the first applications is permitted to access; and, when it is determined that the target data is the permitted data, allowing the first application to access the target data, and when it is determined that the target data is not the permitted data, not allowing the first application to access the target data.

[0026] The program described in claim 9 has a hypervisor, a first operation system and a second operation system that operate independently of each other on the hypervisor, and at least one first application that operates on the first operation system and is capable of accessing a plurality of types of data via the hypervisor and the second operation system, and causes an in-vehicle information processing device to execute the following processes: a process of determining whether or not target data, which is the data that the first application is attempting to access, is the permission data, based on a correspondence list that defines a correspondence between each of the first applications and permission data, which is the data that each of the first applications is permitted to access; and a process of allowing the first application to access the target data when it is determined that the target data is the permission data, and a process of not allowing the first application to access the target data when it is determined that the target data is not the permission data. Effect of the Invention

[0027] As described above, the in-vehicle information processing device, the information processing method, and the program according to the present invention have the excellent effect of being able to monitor the access operation of an application to data based on simple rules. [Brief description of the drawings]

[0028] [Figure 1] 1 is a schematic diagram of a vehicle equipped with an in-vehicle information processing device according to an embodiment. [Diagram 2] 2 is a control block diagram of the in-vehicle information processing device shown in FIG. 1. [Diagram 3] 3 is a schematic diagram showing the hierarchy of the in-vehicle information processing device shown in FIG. 2. [Figure 4] 3 is a diagram showing a correspondence relationship list recorded in the in-vehicle information processing device shown in FIG. 2. [Diagram 5] 3 is a diagram showing a frequency list recorded in the in-vehicle information processing device shown in FIG. 2. [Figure 6] 3 is a functional block diagram of the in-vehicle information processing device shown in FIG. 2. [Figure 7] 3 is a flowchart showing a process performed by the in-vehicle information processing device shown in FIG. 2. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0029] Hereinafter, an embodiment of an in-vehicle information processing device 10, an information processing method, and a program according to the present invention will be described with reference to the drawings.

[0030] FIG. 1 shows a vehicle 12 equipped with an on-board information processing device 10 according to an embodiment. The on-board information processing device 10 is an ECU (Electronic Control Unit). Therefore, in the following description, the on-board information processing device 10 will be referred to as the ECU 10. The vehicle 12 has the ECU 10 and a plurality of ECUs (not shown) other than the ECU 10. The ECU 10 and the plurality of ECUs are ECUs that comply with the AUTOSAR specification. The ECUs 10 and the plurality of ECUs are connected to each other by a bus (not shown). The network including the ECU 10, the plurality of ECUs, and the bus is, for example, CAN, Ethernet (registered trademark), or Flex Ray (registered trademark). The ECU 10 and the plurality of ECUs can transmit and receive various information to each other via the bus.

[0031] 2, the ECU 10 and the multiple ECUs include a CPU (Central Processing Unit: processor) 10A, a ROM (Read Only Memory) 10B, a RAM (Random Access Memory) 10C, a storage 10D, a communication I / F (Interface) 10E, and an input / output I / F 10F. The CPU 10A, the ROM 10B, the RAM 10C, the storage 10D, the communication I / F 10E, and the input / output I / F 10F are connected to each other so as to be able to communicate with each other via a bus 10Z. The ECU 10 and the multiple ECUs can obtain information related to time from a timer (not shown).

[0032] The CPU 10A is a central processing unit that executes various programs and controls each part. That is, the CPU 10A reads various programs (described later) from the ROM 10B or the storage 10D, and executes the programs using the RAM 10C as a working area. The CPU 10A controls each component and performs various arithmetic processing according to the programs recorded in the ROM 10B or the storage 10D.

[0033] The ROM 10B stores various programs and various data. The RAM 10C temporarily stores programs or data as a working area. The storage 10D is composed of a storage device such as a hard disk drive (HDD) or a solid state drive (SSD), and stores various programs and various data. The communication I / F 10E is an interface for the ECU 10 (ECU) to communicate with other devices. The communication I / F 10E is connected to a bus. The input / output I / F 10F is an interface for communicating with each device mounted on the vehicle 12. For example, a wheel speed sensor 14, a steering torque sensor 16, and a coolant temperature sensor 18, which will be described later, are connected to the input / output I / F 10F of the ECU 10.

[0034] As shown in FIG. 3, the ECU 10 has a hardware layer, a hypervisor layer, an OS layer, a middleware layer, and an application layer. In the ROM 10B, the following programs are installed: a hypervisor HV, a first operation system OS1, a second operation system OS2, a third operation system OS3, a first middleware MW1, a second middleware MW2, a third middleware MW3, a non-genuine application 30 (hereinafter referred to as a non-genuine APR 30), a genuine application 32 (hereinafter referred to as a genuine APP 32), and a genuine application 34 (hereinafter referred to as a genuine APP 34). The non-genuine APP 30 is a general term for two non-genuine APPs 30-1 and 30-2. The genuine APP 34 is a general term for three genuine APPs 34-1, 34-2, and 34-3. The genuine APP 32 and the genuine APP 34 are programs created by the vehicle manufacturer that produced the vehicle 12. On the other hand, the non-genuine APP 30 is a program created by a third party.

[0035] The hypervisor HV causes the ECU 10 to function as a virtual machine. The ECU 10 is virtually partitioned into three areas. That is, the ECU 10 is partitioned into a non-trusted area AR1, a public data management area AR2, and a control area AR3. A first operation system OS1 that operates on the hypervisor HV, a first middleware MW1 that operates on the first operation system OS1, and a non-genuine APP30 and a genuine APP32 that operate on the first middleware MW1 are installed in the non-trusted area AR1. A second operation system OS2 that operates independently of the first operation system OS1 on the hypervisor HV, and a second middleware MW2 that operates on the second operation system OS2 are installed in the public data management area AR2. A third operation system OS3 that operates independently of the first operation system OS1 and the second operation system OS2 on the hypervisor HV, a third middleware MW3 that operates on the third operation system OS3, and a genuine APP34 that operates on the third middleware MW3 are installed in the control area AR3.

[0036] The ECU 10 is connected to sensors 14, 16, and 18 that detect physical quantities that change in conjunction with at least one of the traveling, steering, and braking of the vehicle 12. In this embodiment, the sensor 14 is a wheel speed sensor 14 capable of detecting the wheel speed, the sensor 16 is a steering torque sensor 16 capable of detecting the steering torque of the steering wheel, and the sensor 18 is a coolant temperature sensor capable of detecting the engine coolant temperature. However, the sensors 14, 16, and 18 may be configured to detect physical quantities different from these physical quantities (for example, the steering angle of the steering wheel, the yaw rate of the vehicle 12, and the force applied to the brake pedal).

[0037] In this embodiment, the genuine APP 34-1 executes a predetermined control using data related to the wheel speed obtained by the wheel speed sensor 14. The genuine APP 34-2 executes a predetermined control using data related to the steering torque obtained by the steering torque sensor 16. The genuine APP 34-3 executes a predetermined control using data related to the cooling water temperature obtained by the cooling water temperature sensor 18.

[0038] The data regarding wheel speed, steering torque, and coolant temperature obtained by the genuine APP34 are recorded in the public data recording unit 20 constituted by ROM10B or storage 10D via the third middleware MW3, the third operation system OS3, the hypervisor HV, the second operation system OS2, and the second middleware MW2.

[0039] The first middleware MW1 and the second middleware MW2 have programs for realizing two public APIs (Application Programmable Interfaces) 21-1, 21-2 and one native API 22. Hereinafter, the public API 21 may be used as a general term for the public APIs 21-1 and 21-2. Furthermore, the public API 21-1 of the first middleware MW1 and the public API 21-1 of the second middleware MW2 are formed on a virtual communication path realized by the hypervisor HV. Furthermore, the public API 21-2 of the first middleware MW1 and the public API 21-2 of the second middleware MW2 are formed on the virtual communication path. Furthermore, the native API 22 of the first middleware MW1 and the native API 22 of the second middleware MW2 are formed on the virtual communication path.

[0040] Each non-genuine APP 30 can access the public API 21 of the first middleware MW1 and the second middleware MW2. The correspondence list 25 shown in FIG. 4 indicates the correspondence between each non-genuine APP 30 and the public API 21 that each non-genuine APP 30 can access. In other words, the correspondence list 25 specifies the correspondence between each non-genuine APP 30 and permission data, which will be described later. The correspondence list 25 is recorded in a recording section (e.g., ROM 10B) of the non-trusted area AR1 and a recording section (e.g., ROM 10B) of the public data management area AR2. The non-genuine APP 30-1 can access the public API 21-1, and the non-genuine APP 30-2 can access the public API 21-2. The non-genuine APP 30-1 can read and write data related to the wheel speed that is recorded in the public data recording section 20 and is linked to the public API 21-1 by accessing the public API 21-1. The non-genuine APP 30-2 can read and write data related to steering torque that is recorded in the public data recording unit 20 and linked to the public API 21-2 by accessing the public API 21-2. The correspondence list 25 is created based on a contract between the third party that created the non-genuine APP 30 and the vehicle manufacturer. The genuine APP 32 can access the native API 22, and can read and write data related to coolant temperature that is recorded in the public data recording unit 20 and linked to the native API 22 by accessing the native API 22. The non-genuine APP 30 and the genuine APP 32 execute various controls using the acquired data.

[0041] Furthermore, the ROM 10B stores a frequency list 27 shown in FIG. 5. The frequency list 27 specifies a frequency condition that indicates a relationship between each public API 21 and an access frequency set for each public API 21. If the access frequency of the non-genuine APP 30 to the public API 21 is equal to or lower than the frequency specified in the frequency list 27, the access by the non-genuine APP 30 to the public API 21 is considered to be a normal access. On the other hand, if the non-genuine APP 30 accesses the public API 21 at a frequency higher than the frequency specified in the frequency list 27, the access by the non-genuine APP 30 to the public API 21 is considered to be an unauthorized access. The frequency list 27 of this embodiment indicates that the access frequency set for the public API 21-1 is 100 ms (milliseconds), and the access frequency set for the public API 21-2 is 200 ms (milliseconds).

[0042] 6 is a block diagram showing an example of the functional configuration of the ECU 10. The ECU 10 has, as its functional configuration, a first determination unit 101, a first access control unit 102, a second determination unit 103, a second access control unit 104, and an abnormality processing unit 105. The first determination unit 101, the first access control unit 102, the second determination unit 103, the second access control unit 104, and the abnormality processing unit 105 are realized by the CPU 10A reading and executing the hypervisor HV, the first operation system OS1, the second operation system OS2, the first middleware MW1, and the second middleware MW2 stored in the ROM 10B.

[0043] The first determination unit 101 is a function realized by the first middleware MW1. The first determination unit 101 determines whether or not the API accessed by the non-genuine APP 30 is the public API 21. Furthermore, when the first determination unit 101 determines that the non-genuine APP 30 has accessed the public API 21, the first determination unit 101 determines whether or not the accessed public API 21 is a public API 21 that is permitted to be accessed, based on the correspondence list 25. Hereinafter, the API accessed by the non-genuine APP 30 may be referred to as a "target API." Furthermore, when the target API is an API that the non-genuine APP 30 is permitted to access, this target API may be referred to as an "authorized API."

[0044] The first access control unit 102 is a function realized by the first middleware MW1. When the first determination unit 101 determines that the target API 21 is the permitted API 21, the first access control unit 102 permits the non-genuine APP 30 that has accessed the permitted API 21 to access the second middleware MW2 via the first operation system OS1, the hypervisor HV, and the second operation system OS2 along the virtual communication path.

[0045] The second determination unit 103 is a function realized by the second middleware MW2. The second determination unit 103 determines whether the frequency of access to the permitted API 21 by the non-genuine APP 30 determined by the first determination unit 101 to have accessed the permitted API 21 is higher than the frequency specified in the frequency list 27.

[0046] Furthermore, the second determination unit 103 performs the same process as the first determination unit 101, based on the correspondence list 25. That is, the second determination unit 103 determines, based on the correspondence list 25, whether the target API 21 is a permitted API 21 or not.

[0047] The second access control unit 104 is a function realized by the second middleware MW2. When the second determination unit 103 determines that the target API 21 is the permitted API 21, the second access control unit 104 permits the non-genuine APP 30 that has accessed the permitted API 21 to access permitted data that is recorded in the public data recording unit 20 and is linked to the permitted API 21.

[0048] The abnormality processing unit 105 is a function realized by the second middleware MW2. As will be described later, the abnormality processing unit 105 performs necessary processing for the non-genuine APP 30 that has accessed the public API 21, based on the manner in which the non-genuine APP 30 accesses the public API 21.

[0049] Next, the flow of processing performed by the ECU 10 will be described with reference to the flowchart of Fig. 7. The ECU 10 repeatedly executes the processing of the flowchart every time a predetermined time elapses.

[0050] In step S10 , the first determination unit 101 of the ECU 10 determines whether any of the non-genuine APPs 30 has accessed the public API 21 or the native API 22 .

[0051] If the result of the determination in step S10 is Yes, the ECU 10 proceeds to step S11. In step S11, the first determination unit 101 determines whether the non-genuine APP 30 has accessed the public API 21 or not.

[0052] When the result of the determination in step S11 is Yes, the ECU 10 proceeds to step S12. In step S12, the first determination unit 101 determines whether the public API 21 accessed by the non-genuine APP 30 is an authorized API based on the correspondence list 25. In other words, the first determination unit 101 determines whether the target data that the non-genuine APP 30 is attempting to access is authorized data. For example, when the non-genuine APP 30 is non-genuine APP 30-1, the first determination unit 101 determines whether the non-genuine APP 30-1 has accessed the public API 21-1.

[0053] If the result of the determination in step S12 is Yes, the ECU 10 proceeds to step S13. In step S13, the first access control unit 102 permits the non-genuine APP 30 that has accessed the permitted API 21 to access the second middleware MW2 via the first operation system OS1, the hypervisor HV, and the second operation system OS2.

[0054] After completing the process of step S13, the ECU 10 proceeds to step S14, where the second judgment unit 103 judges whether the access frequency of the non-genuine APP 30 to the permitted API 21 is equal to or less than the frequency specified in the frequency list 27. When the non-genuine APP 30-1 accesses the public API 21-1, the second judgment unit 103 judges whether the non-genuine APP 30-1 repeatedly accesses the public API 21-1 at intervals shorter than 100 ms. When the access frequency of the non-genuine APP 30 is equal to or less than the frequency specified in the frequency list 27, the second judgment unit 103 judges Yes in step S14, and the ECU 10 proceeds to step S15.

[0055] In step S15, the second determination unit 103 determines, based on the correspondence list 25, whether the public API 21 accessed by the non-genuine APP 30 is an authorized API.

[0056] If the result of the determination in step S15 is Yes, the ECU 10 proceeds to step S16. In step S16, the second access control unit 104 permits the non-genuine APP 30 that has accessed the permitted API 21 to access the permitted data recorded in the public data recording unit 20. Therefore, the non-genuine APP 30 can obtain the permitted data. In addition, the non-genuine APP 30 that has accessed the permitted data can rewrite the permitted data.

[0057] When the ECU 10 makes a negative determination in step S11, S12, or S14, the ECU 10 proceeds to step S17.

[0058] In step S17, the abnormality processing unit 105 of the ECU 10 increments the NG count by "1." The initial value of the NG count is "0."

[0059] After completing the process of step S17, the ECU 10 proceeds to step S18, where the abnormality processing unit 105 determines whether the total value of the NG count number is equal to or greater than a threshold value. This threshold value is a natural number equal to or greater than 2. The threshold value is recorded in the ROM 10B or the storage 10D.

[0060] If the result of the determination in step S18 is Yes, the ECU 10 proceeds to step S19. In step S19, the abnormality processing unit 105 prohibits the non-genuine APP 30 for which the result of the determination in step S18 is Yes from accessing the public API 21 for a predetermined time. The abnormality processing unit 105 determines whether the predetermined time has elapsed based on information acquired from the timer.

[0061] After completing the process of step S19, the ECU 10 proceeds to step S20, where the abnormality processing unit 105 sets the total value of the NG count number to "0."

[0062] When the second determination unit 103 determines "No" in step S15, the ECU 10 proceeds to step S21. The abnormality processing unit 105 in step S21 uninstalls from the ECU 10 the non-genuine APP 30 for which the determination in step S15 is "No."

[0063] When the process of step S16, S20 or S21 is completed, or when the determination in step S10 or S18 is No, the ECU 10 temporarily ends the process of the flowchart.

[0064] (Action and Effects) Next, the operation and effects of this embodiment will be described.

[0065] The correspondence list 25 of the ECU 10 of this embodiment defines rules that indicate the correspondence between each non-genuine APP 30 and the permitted API 21 to which each non-genuine APP 30 is permitted to access. The first determination unit 101 realized by the first middleware MW1 monitors the access operation of the non-genuine APP 30 to the data recorded in the public data recording unit 20 based on the correspondence list 25. The rules defined by the correspondence list 25 are simpler than rules that define all processes (behaviors) of all non-genuine APPs 30. Therefore, the ECU 10 of this embodiment can monitor the access operation of the non-genuine APP 30 to each data recorded in the public data recording unit 20 based on simple rules. Therefore, the calculation load on the ECU 10 is not large. Therefore, it is not necessary to construct the ECU 10 using an expensive hardware configuration.

[0066] Furthermore, in the ECU 10, the second determination unit 103 implemented by the second middleware MW2 monitors the access operation of the non-genuine APP 30 determined by the first determination unit 101 to have accessed the permitted API, to the data recorded in the public data recording unit 20, based on the correspondence list 25. Since the access of the non-genuine APP 30 to the public data recording unit 20 is monitored twice in this manner, it is possible to determine with high accuracy whether the target API 21 accessed by the non-genuine APP 30 is the permitted API 21.

[0067] Furthermore, in the ECU 10, the first determination unit 101 monitors the access operation of the non-genuine APP 30 to the data recorded in the public data recording unit 20. Therefore, the calculation load in the public data management area AR2 of the ECU 10 is less likely to be high compared to a case in which the ECU 10 does not include the first determination unit 101 and the first access control unit 102.

[0068] Furthermore, the frequency list 27 specifies a frequency condition that indicates the relationship between each public API 21 and the access frequency set for each public API 21. When the second determination unit 103 determines that the access frequency to the permitted API 21 by the non-genuine APP 30 does not satisfy the frequency condition, the second access control unit 104 does not permit the non-genuine APP 30 to access the permitted data. The rules related to the frequency condition specified by the frequency list 27 are simpler than rules that define all processes of all non-genuine APPs 30. Therefore, the ECU 10 can monitor the access operation of the non-genuine APP 30 to each data recorded in the public data recording unit 20 based on the simple rules.

[0069] Furthermore, in step S15, the non-genuine APP 30 determined by the second determination unit 103 to have accessed the public API 21 that is not an authorized API is an application that should be prohibited by the first determination unit 101 from accessing the first operation system OS1, the hypervisor HV, the second operation system OS2, and the second middleware MW2. Nevertheless, the non-genuine APP 30 passes the check by the first determination unit 101 and attempts to access the first operation system OS1, the hypervisor HV, the second operation system OS2, and the second middleware MW2. Therefore, the access by the non-genuine APP 30 to the public API 21 is considered to be an extremely dangerous unauthorized access. Therefore, the abnormality processing unit 105 uninstalls the non-genuine APP 30 from the ECU 10. Therefore, it is possible to protect the ECU 10 from the non-genuine APP 30 that may perform a highly dangerous attack.

[0070] The unauthorized access by the non-genuine APP 30 determined as No in steps S11 and S12 by the first determination unit 101 and the unauthorized access by the non-genuine APP 30 determined as No in step S14 by the second determination unit 103 are less dangerous than the unauthorized access by the non-genuine APP 30 determined as No in step S15. Therefore, in this embodiment, such a non-genuine APP 30 is not uninstalled from the ECU 10. In other words, the abnormality processing unit 105 prohibits the non-genuine APP 30 that has repeatedly performed such unauthorized access more than the threshold from accessing the public API 21 for a predetermined time.

[0071] Furthermore, the public data recording unit 20 records data on physical quantities that change in conjunction with at least one of the traveling, steering, and braking of the vehicle 12, which are acquired by the genuine APP 34. In this embodiment, it is possible to prevent unauthorized access to these data by the non-genuine APP 30. Therefore, there is little risk that the non-genuine APP 30 that has acquired these data unauthorizedly will execute control based on these data.

[0072] Although the ECU 10 according to this embodiment has been described above, the design of the ECU 10 can be appropriately modified without departing from the gist of the present invention.

[0073] The ECU 10 may not include the second determination unit 103 and the second access control unit 104. In this case, the non-genuine application 30 determined by the first determination unit 101 to have accessed the permitted API is permitted to access the permitted data by the first access control unit 102.

[0074] The ECU 10 may not include the first determination unit 101 and the first access control unit 102. In this case, the non-genuine application 30 that is determined by the second determination unit 103 to have accessed the permitted API is permitted to access the permitted data by the second access control unit 104.

[0075] The abnormality processing unit 105 may execute only one of the processes of steps S17 to S20 and the process of step S21.

[0076] All applications installed in the non-trusted area AR1 may be applications created by the vehicle manufacturer, and all APIs in the non-trusted area AR1 and the public data management area AR2 may be native APIs. Also, all applications installed in the non-trusted area AR1 may be applications created by a third party, and all APIs in the non-trusted area AR1 and the public data management area AR2 may be public APIs.

[0077] The abnormality processing unit 105 may monitor the operation status of at least one of the first operation system OS1 and the first middleware MW1 based on a system log recorded by at least one of the first operation system OS1 and the first middleware MW1. Furthermore, the abnormality processing unit 105 may temporarily stop the operation of the entire non-trusted area AR1 when it is determined that at least one of the first operation system OS1 and the first middleware MW1 is executing an unauthorized process based on the operation status.

[0078] For example, when a new non-genuine APP 30 is downloaded to the ECU 10 via the Internet, the correspondence list 25 may be updated so that information regarding the correspondence between the non-genuine APP 30 and the public API 21 (authorized API) is recorded.

[0079] Any number of applications may be installed in the non-trusted area AR1 and any number of applications may be installed in the control area AR3. Also, any number of APIs may be installed in the non-trusted area AR1 and the public data management area AR2.

[0080] The public data recording unit 20 may record data of a type other than data regarding physical quantities that change in conjunction with at least one of the running, steering, and braking of the vehicle. [Explanation of symbols]

[0081] 10 ECU (In-vehicle information processing unit) 10B ROM (recording section) (first recording section) (second recording section) (third recording section) 10D Storage (recording section) (1st recording section) (2nd recording section) (3rd recording section) 101 First judgment section (judgment section) 102 First access control unit (access control unit) 103 Second judgment section (judgment section) 104 Second access control unit (access control unit) 105 Abnormality Processing Unit 20 Public Data Recording Unit (Recording Unit) (First Recording Unit) 21(21-1, 21-2) Public API (API) 25 Correspondence List 27 Frequency List 30 (30-1, 30-2) Non-genuine application (non-genuine APP) (first application) (program) 34 (34-1, 34-2, 34-3) Original application (second application) (program) HV Hypervisor (program) OS1 First operating system (program) OS2 Second operating system (program) MW1 1st middleware (program) MW2 2nd middleware (program)

Claims

1. An in-vehicle information processing device in which a hypervisor, a first operation system and a second operation system which operate independently of each other on the hypervisor, and at least one first application which operates on the first operation system are installed, a first recording unit in which a plurality of types of data that can be accessed by the first application via the hypervisor and the second operation system is recorded; a second recording unit in which a correspondence list is recorded, the correspondence list defining a correspondence between each of the first applications and permission data, which is the data to which each of the first applications is permitted to access; a determination unit that determines whether or not the target data that the first application is attempting to access is the permission data based on the correspondence relationship list; an access control unit that permits the first application to access the target data when the determination unit determines that the target data is the permission data, and does not permit the first application to access the target data when the determination unit determines that the target data is not the permission data; An in-vehicle information processing device comprising:

2. a first middleware that operates on the first operating system and realizes at least one API (Application Programmable Interface); each of the first applications runs on the first middleware; the correspondence list defines a correspondence between each of the first applications and an authorized API that is the API to which each of the first applications is authorized to access and that can obtain the authorized data by accessing the first application; The determination unit, a first determination unit implemented by the first middleware that, when it is determined that the first application has accessed a target API that is at least one of the APIs, determines whether the target API is one of the permitted APIs based on the correspondence relationship list; The access control unit:

2. The in-vehicle information processing device according to claim 1, further comprising a first access control unit realized by the first middleware that allows the first application determined by the first determination unit to have accessed the permitted API to access the second operation system via the first operation system and the hypervisor.

3. a second middleware running on the second operating system realizing at least one of the APIs; The determination unit, a second determination unit implemented by the second middleware that determines, based on the correspondence relationship list, whether the target API accessed by the first application determined by the first determination unit to have accessed the permitted API is the permitted API; The access control unit: The in-vehicle information processing device according to claim 2 , further comprising a second access control unit realized by the second middleware that permits the first application to access the permitted data when the second determination unit determines that the target API is the permitted API.

4. a third recording unit in which a frequency list is recorded that defines a frequency condition that is a condition regarding an access frequency of the first application to the permitted API; The in-vehicle information processing device according to claim 3 , wherein when the second determination unit determines that the frequency of access by the first application to the authorized API does not satisfy the frequency condition, the second access control unit does not allow the first application to access the authorized data.

5. 5. The in-vehicle information processing device according to claim 3, further comprising an abnormality processing unit realized by the second middleware, which uninstalls the first application that has accessed the target API that is determined by the second determination unit to be not the permitted API from the in-vehicle information processing device.

6. The in-vehicle information processing device according to any one of claims 3 to 5, wherein the data recorded in the first recording unit is data acquired by at least one second application operating on a third operation system that operates independently of the first operation system and the second operation system on the hypervisor.

7. The in-vehicle information processing device according to claim 6 , wherein at least one of the second applications acquires data on a physical quantity that changes in conjunction with at least one of running, steering, and braking of the vehicle in which the in-vehicle information processing device is mounted.

8. An information processing method performed by an in-vehicle information processing device having installed therein a hypervisor, a first operation system and a second operation system which operate independently of each other on the hypervisor, and at least one first application which operates on the first operation system, comprising: a step of determining whether or not target data, which is the data that the first application is attempting to access, is the permission data, based on a correspondence list that defines a correspondence between the first application and permission data, which is the data that each of the first applications is permitted to access, when the first application attempts to access a recording unit in which a plurality of types of data are recorded via the hypervisor and the second operation system; permitting the first application to access the target data when it is determined that the target data is the permission data, and not permitting the first application to access the target data when it is determined that the target data is not the permission data; An information processing method comprising the steps of:

9. Hypervisor, a first operation system and a second operation system that operate independently of each other on the hypervisor; and at least one first application running on the first operating system that is capable of accessing a plurality of types of data via the hypervisor and the second operating system; having a process of determining whether or not target data, which is the data that the first application is attempting to access, is the permission data, based on a correspondence list that defines a correspondence between each of the first applications and permission data, which is the data that each of the first applications is permitted to access; a process of permitting the first application to access the target data when it is determined that the target data is the permission data, and not permitting the first application to access the target data when it is determined that the target data is not the permission data; A program for causing an in-vehicle information processing device to execute the above.

Images