In-Vehicle Information Processing Device, Information Processing Method, and Storage Medium

Abstract

The present invention relates to an in-vehicle information processing device, an information processing method, and a storage medium. A processor determines whether the data to be accessed by a first application, that is, the object data, is permitted data based on a correspondence list. When the processor determines that the object data is permitted data, the processor permits the first application to access the object data. When the processor determines that the object data is not permitted data, the processor does not permit the first application to access the object data.

Description

Technical Field

[0001] The present disclosure relates to an in-vehicle information processing device, an information processing method, and a storage medium. Background Art

[0002] Japanese Unexamined Patent Application Publication No. 2019-8503 discloses an information processing device as follows: when it is determined that a process of an application is an attack based on a rule that defines what process (action) of an application (program) is an attack on the CPU, the process is invalidated.

[0003] Various applications may be installed in the in-vehicle information processing device. For example, an application created by an organization other than the vehicle manufacturer that manufactures the vehicle equipped with the in-vehicle information processing device, that is, a third party, may be installed in the in-vehicle information processing device. In this case, there is a concern that the application illegally accesses the data recorded in the in-vehicle information processing device. That is, there is a possibility that the application attacks the in-vehicle information processing device.

[0004] In Japanese Unexamined Patent Application Publication No. 2019-8503, in order to determine whether all processes of an application belong to an attack, it is necessary to make the above rule a complex rule. Therefore, when applying the technical idea of Japanese Unexamined Patent Application Publication No. 2019-8503 to the in-vehicle information processing device, the computational load imposed on the in-vehicle information processing device becomes large. Therefore, it is necessary to use an expensive hardware structure to construct the in-vehicle information processing device. Summary of the Invention

[0005] In consideration of the above facts, an object of the present disclosure is to obtain an in-vehicle information processing device, an information processing method, and a storage medium that can monitor the access action of an application to data based on a simple rule.

[0006] The in-vehicle information processing device according to the first aspect of the present disclosure includes: a processor that reads and executes a hypervisor, a first operating system and a second operating system that operate independently of each other on the hypervisor, and at least one first application that operates on the first operating system; a first recording unit that records a plurality of types of data that the first application can access via the hypervisor and the second operating system; and a second recording unit that records a correspondence list that defines the correspondence between each first application and the data that each first application is allowed to access, that is, allowed data; the processor determines whether the data to be accessed by the first application, that is, the target data, is the allowed data based on the correspondence list, and when the processor determines that the target data is the allowed data, the processor allows the first application to access the target data, and when the processor determines that the target data is not the allowed data, the processor does not allow the first application to access the target data.

[0007] The in-vehicle information processing apparatus according to the first aspect of the present disclosure includes a first recording unit that records a plurality of types of data that at least one first application operating on a first operating system can access via a virtual machine monitor and a second operating system. The in-vehicle information processing apparatus also includes a second recording unit that records a correspondence list that defines the correspondence between each first application and the data that each first application is permitted to access, i.e., the permitted data. The processor determines, based on the correspondence list, whether the data that the first application attempts to access, i.e., the target data, is permitted data. When the processor determines that the target data is permitted data, the processor permits the first application to access the target data.

[0008] In this way, the access operation of the first application to the data can be monitored based on the rule defining the correspondence between each first application and the permitted data specified in the correspondence list. The rule defining the correspondence between each first application and the permitted data is simpler than the rule defining all the processes (actions) of all the first applications. Therefore, in the in-vehicle information processing apparatus according to the first aspect of the present disclosure, the access operation of the first application to the data can be monitored based on a simple rule. As a result, the computational load on the in-vehicle information processing apparatus does not increase. Therefore, there is no need to use an expensive hardware structure to construct the in-vehicle information processing apparatus.

[0009] In the in-vehicle information processing apparatus according to the second aspect of the present disclosure, a first middleware operating on the first operating system implements at least one API (Application Programmable Interface), each of the first applications operates on the first middleware, the correspondence list defines the correspondence between each first application and the permitted APIs among the APIs that each first application is permitted to access, and the permitted data can be obtained by accessing the permitted APIs by each first application. When the processor determines, by executing the first middleware, that the first application has accessed at least one of the APIs, i.e., the target API, the processor determines, based on the correspondence list, whether the target API is a permitted API. The processor permits the first application, which the processor determines, by executing the first middleware, has accessed the permitted API, to access the second operating system via the first operating system and the virtual machine monitor.

[0010] In the in-vehicle information processing apparatus according to the second aspect of the present disclosure, a first middleware operating on a first operating system implements at least one API, and each first application operates on the first middleware. When the processor determines, by executing the first middleware, that a first application has accessed at least one API, that is, an object API, the processor determines whether the object API is a permitted API based on a correspondence list. The processor permits the first application that has been determined by the processor to have accessed a permitted API by executing the first middleware to access a second operating system via the first operating system and a virtual machine monitor.

[0011] In this way, the access operation of the first application to data can be monitored based on the rule defining the correspondence between each first application and the permitted API specified in the correspondence list. The rule defining the correspondence between each first application and the permitted API is simpler than the rule defining all processes of all the first applications. Therefore, the in-vehicle information processing apparatus according to the second aspect of the present disclosure can monitor the access operation of the first application to data based on a simple rule.

[0012] In the in-vehicle information processing apparatus according to the third aspect of the present disclosure, a second middleware operating on the second operating system implements at least one of the above-mentioned APIs. The processor determines, based on the correspondence list, whether the object API accessed by the first application determined by the processor to have accessed the permitted API by executing the second middleware is the permitted API. When the processor determines, by executing the second middleware, that the object API is the permitted API, the processor permits the first application to access the permitted data.

[0013] In the in-vehicle information processing apparatus according to the third aspect of the present disclosure, a second middleware operating on the second operating system implements at least one API. The processor determines, based on the correspondence list, whether the object API accessed by the first application determined by the processor to have accessed the permitted API by executing the second middleware is the permitted API. When the processor determines, by executing the second middleware, that the object API is the permitted API, the processor permits the first application to access the permitted data.

[0014] In this way, the access operation of the first application to data can be monitored based on the rule defining the correspondence between each first application and the permitted API specified in the correspondence list. The rule defining the correspondence between each first application and the permitted API is simpler than the rule defining all processes of all the first applications. Therefore, the in-vehicle information processing apparatus according to the third aspect of the present disclosure can monitor the access operation of the first application to data based on a simple rule.

[0015] Further, in the in-vehicle information processing apparatus according to the third aspect of the present disclosure, the processor that executes the second middleware determines, based on the correspondence list, whether the object API accessed by the first application determined by the processor that executes the first middleware to have accessed the permitted API is a permitted API. In this way, since the access of the first application to the data (the first recording unit) is monitored twice, it is possible to determine with higher accuracy whether the object API accessed by the first application is a permitted API.

[0016] The in-vehicle information processing apparatus according to the fourth aspect of the present disclosure includes a third recording unit that records a frequency list defining conditions (i.e., frequency conditions) related to the access frequency of the first application to the permitted API. When the processor determines that the access frequency of the first application to the permitted API does not satisfy the frequency conditions, the first application is not permitted to access the permitted data.

[0017] The in-vehicle information processing apparatus according to the fourth aspect of the present disclosure includes a third recording unit that records a frequency list defining conditions (i.e., frequency conditions) related to the access frequency of the first application to the permitted API. Further, when the processor determines that the access frequency of the first application to the permitted API does not satisfy the frequency conditions, the processor does not permit the first application to access the permitted data. The rules related to the frequency conditions are simpler than the rules defining all processes of all the first applications. Therefore, the in-vehicle information processing apparatus according to the fourth aspect of the present disclosure can monitor the access actions of the first application to the data based on simple rules.

[0018] In the in-vehicle information processing apparatus according to the fifth aspect of the present disclosure, the processor uninstalls the first application that has accessed the object API determined by the processor to be not the permitted API by executing the second middleware from the in-vehicle information processing apparatus.

[0019] It can be considered that the access of the first application to the object API determined by the processor that executes the second middleware to be not the permitted API is a process with a high risk. That is, there is a concern that such a first application may perform a highly dangerous attack on the in-vehicle information processing apparatus. In the in-vehicle information processing apparatus according to the fifth aspect of the present disclosure, the processor uninstalls the first application that has accessed the object API determined by the processor that executes the second middleware to be not the permitted API from the in-vehicle information processing apparatus. Therefore, the fifth aspect of the present disclosure can protect the in-vehicle information processing apparatus from the influence of the first application that may perform a highly dangerous attack.

[0020] For the vehicle-mounted information processing device involved in the sixth mode of the present disclosure, the above-mentioned data recorded in the above-mentioned first recording unit is data obtained by at least one second application operating on the third operating system, and the third operating system operates independently from the above-mentioned first operating system and the above-mentioned second operating system on the above-mentioned virtual machine monitor.

[0021] In the in-vehicle information processing device according to the sixth aspect of the present disclosure, it is possible to monitor, based on simple rules, the access operation of the first application to data acquired by at least one second application operating on the third operating system.

[0022] For the vehicle-mounted information processing device involved in the 7th mode of the present disclosure, at least one of the above-mentioned second applications obtains data related to at least one physical quantity that changes in conjunction with the driving, steering control and braking of the vehicle equipped with the above-mentioned vehicle-mounted information processing device.

[0023] In the in-vehicle information processing device according to the seventh aspect of the present disclosure, it is possible to monitor the access actions of the first application to data related to at least one physical quantity that changes in conjunction with the driving, steering, and braking of the vehicle equipped with the in-vehicle information processing device based on simple rules. Therefore, there is less concern that the first application that may attack the in-vehicle information processing device may illegally obtain the data.

[0024] In the information processing method involved in the 8th mode of the present disclosure, by reading and executing a virtual machine monitor, a first operating system and a second operating system that operate independently of each other on the above-mentioned virtual machine monitor, and a processor of at least one first application that operates on the above-mentioned first operating system, when the above-mentioned first application attempts to access a recording unit that records multiple types of data via the above-mentioned virtual machine monitor and the above-mentioned second operating system, based on a correspondence list that stipulates the correspondence between the above-mentioned first application and the above-mentioned data that each of the above-mentioned first applications is allowed to access, that is, the allowed data, it is determined whether the above-mentioned data, that is, the object data, that the above-mentioned first application attempts to access is the above-mentioned allowed data; when it is determined that the above-mentioned object data is the above-mentioned allowed data, the above-mentioned first application is allowed to access the above-mentioned object data, and when it is determined that the above-mentioned object data is not the above-mentioned allowed data, the above-mentioned first application is not allowed to access the above-mentioned object data.

[0025] The storage medium according to the ninth aspect of the present disclosure stores a program and is readable by a computer. The above program includes: a virtual machine monitor, a first operating system and a second operating system that operate independently on the above virtual machine monitor, and at least one first application that can access multiple types of data via the above virtual machine monitor and the above second operating system and operates on the above first operating system. When the program is executed by a processor, the following steps are performed: when the above first application attempts to access a recording unit that records multiple types of data via the above virtual machine monitor and the above second operating system, determining whether the data to be accessed by the above first application, that is, the target data, is the above permitted data based on a correspondence list that defines the correspondence between the above first application and the above data that each first application is permitted to access, that is, the permitted data; and when it is determined that the above target data is the above permitted data, allowing the above first application to access the above target data, and when it is determined that the above target data is not the above permitted data, not allowing the above first application to access the above target data.

[0026] As described above, the in-vehicle information processing device, information processing method, and storage medium according to the present disclosure have an excellent effect of being able to monitor the access actions of applications to data based on simple rules. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Exemplary embodiments of the present invention will be described in detail with reference to the following figures, wherein:

[0028] Figure 1 is a schematic diagram of a vehicle equipped with the in-vehicle information processing device according to the embodiment.

[0029] Figure 2 is Figure 1 a control block diagram of the in-vehicle information processing device shown.

[0030] Figure 3 is a schematic diagram showing Figure 2 the hierarchy of the in-vehicle information processing device shown.

[0031] Figure 4 is a diagram showing Figure 2 the correspondence list of the in-vehicle information processing device shown.

[0032] Figure 5 is a diagram showing Figure 2 the frequency list of the in-vehicle information processing device shown.

[0033] Figure 6 is Figure 2 a functional block diagram of the in-vehicle information processing device shown.

[0034] Figure 7 It represents Figure 2 a flowchart of the processing performed by the in-vehicle information processing device shown Detailed implementation manners

[0035] Hereinafter, embodiments of the in-vehicle information processing device 10, information processing method, and storage medium according to the present disclosure will be described with reference to the accompanying drawings.

[0036] Figure 1 Reference numeral 12 denotes a vehicle equipped with the in-vehicle information processing device 10 of the embodiment. The in-vehicle information processing device 10 is an ECU (Electronic Control Unit). Therefore, in the following description, the in-vehicle information processing device 10 will be referred to as ECU 10. The vehicle 12 has the ECU 10 and a plurality of ECUs different from the ECU 10 (not shown). The ECU 10 and the plurality of ECUs are ECUs compliant with the AUTOSAR standard. The ECU 10 and the plurality of ECUs are interconnected via a bus (not shown). A network having the ECU 10, the plurality of ECUs, and the bus is, for example, CAN, Ethernet (registered trademark), or FlexRay (registered trademark). The ECU 10 and the plurality of ECUs can mutually transmit and receive various information via the bus.

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

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

[0039] The ROM 10B stores various programs and various data. The RAM 10C serves as a working area to temporarily store programs or data. The storage 10D is composed of storage devices such as HDD (Hard Disk Drive) or SSD (Solid State Drive), 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 the bus. The input / output I / F 10F is an interface for communicating with each device mounted on the vehicle 12. For example, the wheel speed sensor 14, the steering torque sensor 16, and the coolant temperature sensor 18 described later are connected to the input / output I / F 10F of the ECU 10.

[0040] As Figure 3 shown, 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 hypervisor HV, the first operating system OS1, the second operating system OS2, the third operating system OS3, the first middleware MW1, the second middleware MW2, the third middleware MW3, non-genuine applications 30 (hereinafter referred to as non-genuine APR 30), genuine applications 32 (hereinafter referred to as genuine APP 32), and genuine applications 34 (hereinafter referred to as genuine APP 34) are installed as the above-mentioned programs. Among them, the non-genuine APP 30 is a collective term for two non-genuine APPs 30-1 and 30-2. The genuine APP 34 is a collective 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 manufactured the vehicle 12. On the other hand, the non-genuine APP 30 is a program created by a third party.

[0041] ECU10 functions as a virtual machine through the virtual machine monitor HV. ECU10 is virtually divided into three areas. That is, ECU10 is divided into an unreliable area AR1, a public data management area AR2, and a control area AR3. In the unreliable area AR1, the first operating system OS1 that operates on the virtual machine monitor HV, the first middleware MW1 that operates on the first operating system OS1, and the non-genuine APP30 and the genuine APP32 that operate on the first middleware MW1 are installed. In the public data management area AR2, the second operating system OS2 that operates independently from the first operating system OS1 on the virtual machine monitor HV and the second middleware MW2 that operates on the second operating system OS2 are installed. In the control area AR3, the third operating system OS3 that operates independently from the first operating system OS1 and the second operating system OS2 on the virtual machine monitor HV, the third middleware MW3 that operates on the third operating system OS3, and the genuine APP34 that operates on the third middleware MW3 are installed.

[0042] 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 driving, steering, and braking of the vehicle 12. The sensor 14 of this embodiment is a wheel speed sensor 14 that can detect the wheel speed, the sensor 16 is a steering torque sensor 16 that can detect the steering torque of the steering wheel, and the sensor 18 is a cooling water temperature sensor that can detect the cooling water temperature of the engine. The sensors 14, 16, and 18 may also be configured to detect physical quantities different from these physical quantities (e.g., the steering angle of the steering wheel, the yaw rate of the vehicle 12, and the pedal force of the brake pedal).

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

[0044] The data related to the wheel speed, the data related to the steering torque and the data related to the cooling water temperature obtained by the pure APP34 are recorded in the public data recording unit 20 composed of ROM10B or the storage 10D via the third middleware MW3, the third operating system OS3, the virtual machine monitor HV, the second operating system OS2 and the second middleware MW2.

[0045] The first middleware MW1 and the second middleware MW2 have programs for implementing two open APIs (Application Programmable Interfaces) 21-1, 21-2 and one native API 22. Hereinafter, there is a case where the open API 21 is used as a collective term for the open API 21-1 and the open API 21-2. Also, on the virtual communication path implemented by the virtual machine monitor HV, the open API 21-1 of the first middleware MW1 and the open API 21-1 of the second middleware MW2 are formed. And on the virtual communication path, the open API 21-2 of the first middleware MW1 and the open API 21-2 of the second middleware MW2 are formed. And on the virtual communication path, the native API 22 of the first middleware MW1 and the native API 22 of the second middleware MW2 are formed.

[0046] Each non-genuine APP30 can access the open APIs 21 of the first middleware MW1 and the second middleware MW2. Figure 4 The shown correspondence list 25 represents the correspondence between each non-genuine APP30 and the open APIs 21 that each non-genuine APP30 can access. In other words, the correspondence list 25 defines the correspondence between each non-genuine APP30 and the permitted data described later. The correspondence list 25 is respectively recorded in the recording unit (e.g., ROM10B) of the non-trusted area AR1 and the recording unit (e.g., ROM10B) of the public data management area AR2. The non-genuine APP30-1 can access the open API 21-1, and the non-genuine APP30-2 can access the open API 21-2. By the non-genuine APP30-1 accessing the open API 21-1, it is possible to read and write the wheel speed-related data recorded in the public data recording unit 20 and associated with the open API 21-1. By the non-genuine APP30-2 accessing the open API 21-2, it is possible to read and write the steering torque-related data recorded in the public data recording unit 20 and associated with the open API 21-2. The correspondence list 25 is created based on the contract between the third party that created the non-genuine APP30 and the vehicle manufacturer. In addition, the genuine APP32 can access the native API 22, and by accessing the native API 22, it is possible to read and write the coolant temperature-related data recorded in the public data recording unit 20 and associated with the native API 22. The non-genuine APP30 and the genuine APP32 use the obtained data to perform various controls.

[0047] And, it is recorded in ROM10B Figure 5The frequency list 27 shown. The frequency list 27 defines frequency conditions indicating the relationship between each public API 21 and the access frequency set for each public API 21 respectively. When the access frequency of the non-genuine APP 30 to the public API 21 is below the frequency specified in the frequency list 27, it can be considered that the access of the non-genuine APP 30 to the public API 21 is a normal access. On the other hand, when the non-genuine APP 30 accesses the public API 21 at a frequency higher than the frequency specified in the frequency list 27, it can be considered that the access of the non-genuine APP 30 to the public API 21 is an illegal access. The frequency list 27 of the present 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).

[0048] Figure 6 An example of the functional structure of the ECU 10 is shown in a block diagram. The ECU 10 has a first determination unit 101, a first access control unit 102, a second determination unit 103, a second access control unit 104, and an exception handling unit 105 as its functional structure. The first determination unit 101, the first access control unit 102, the second determination unit 103, the second access control unit 104, and the exception handling unit 105 are implemented by the CPU 10A reading and executing the virtual machine monitor HV, the first operating system OS1, the second operating system OS2, the first middleware MW1, and the second middleware MW2 stored in the ROM 10B.

[0049] The first determination unit 101 is a function implemented by the first middleware MW1. The first determination unit 101 determines whether the API accessed by the non-genuine APP 30 is the public API 21. And when the first determination unit 101 determines that the non-genuine APP 30 has accessed the public API 21, it determines whether the accessed public API 21 is an allowed public API 21 based on the correspondence list 25. Hereinafter, there is a case where the API accessed from the non-genuine APP 30 is referred to as an "object API". And when the object API is an API allowed for the non-genuine APP 30 to access, there is a case where the object API is referred to as an "allowed API".

[0050] The first access control unit 102 is a function implemented by the first middleware MW1. When the first determination unit 101 determines that the object API 21 is the allowed API 21, the first access control unit 102 allows the non-genuine APP 30 that has accessed the allowed API 21 to access the second middleware MW2 along the virtual communication path via the first operating system OS1, the virtual machine monitor HV, and the second operating system OS2.

[0051] The second determination unit 103 is a function implemented by the second middleware MW2. The second determination unit 103 determines whether the access frequency of the unauthentic APP 30 that has been determined by the first determination unit 101 to have accessed the permitted API 21 to the permitted API 21 is higher than the frequency specified in the frequency list 27.

[0052] Moreover, the second determination unit 103 performs the same processing as the first determination unit 101 based on the correspondence list 25. That is, the second determination unit 103 determines whether the target API 21 is the permitted API 21 based on the correspondence list 25.

[0053] The second access control unit 104 is a function implemented 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 allows the unauthentic APP 30 that has accessed the permitted API 21 to access the data recorded in the public data recording unit 20 and associated with the permitted API 21, that is, the permitted data.

[0054] The exception handling unit 105 is a function implemented by the second middleware MW2. As will be described later, the exception handling unit 105 performs necessary processing on the unauthentic APP 30 that has accessed the public API 21 based on the access method of the unauthentic APP 30 to the public API 21.

[0055] Next, the Figure 7 flowchart is used to explain the processing flow of the ECU 10. Every time a specified time elapses, the ECU 10 repeatedly executes the processing of the flowchart.

[0056] In step S10, the first determination unit 101 of the ECU 10 determines whether any unauthentic APP 30 has accessed the public API 21 or the local API 22.

[0057] When it is determined in step S10 that "yes", the ECU 10 proceeds to step S11. In step S11, the first determination unit 101 determines whether the unauthentic APP 30 has accessed the public API 21.

[0058] When it is determined in step S11 that "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 unauthentic APP 30 is a permitted API based on the correspondence list 25. In other words, the first determination unit 101 determines whether the data that the unauthentic APP 30 attempts to access, that is, the target data, is permitted data. For example, when this unauthentic APP 30 is the unauthentic APP 30-1, the first determination unit 101 determines whether the unauthentic APP 30-1 has accessed the public API 21-1.

[0059] When the determination in step S12 is "Yes", the ECU 10 proceeds to step S13. In step S13, the first access control unit 102 allows the unauthentic APP 30 that has accessed the permitted API 21 to access the second middleware MW2 via the first operating system OS1, the hypervisor HV, and the second operating system OS2.

[0060] The ECU 10 that has completed the process of step S13 proceeds to step S14, and the second determination unit 103 determines whether the access frequency of the unauthentic APP 30 to the permitted API 21 is equal to or lower than the frequency specified in the frequency list 27. When the unauthentic APP 30-1 has accessed the public API 21-1, the second determination unit 103 determines whether the unauthentic APP 30-1 repeatedly accesses the public API 21-1 at intervals shorter than 100 ms. When the access frequency of the unauthentic APP 30 is equal to or lower than the frequency specified in the frequency list 27, the second determination unit 103 determines "Yes" in step S14, and the ECU 10 proceeds to step S15.

[0061] The second determination unit 103 that has proceeded to step S15 determines, based on the correspondence list 25, whether the public API 21 accessed by the unauthentic APP 30 is a permitted API.

[0062] When the determination in step S15 is "Yes", the ECU 10 proceeds to step S16. In step S16, the second access control unit 104 allows the unauthentic APP 30 that has accessed the permitted API 21 to access the permitted data recorded in the public data recording unit 20. Therefore, the unauthentic APP 30 can acquire the permitted data. In addition, the unauthentic APP 30 that has accessed the permitted data can rewrite the permitted data.

[0063] When the ECU 10 determines "No" in step S11, S12, or S14, the ECU 10 proceeds to step S17.

[0064] The abnormality handling unit 105 of the ECU 10 that has proceeded to step S17 increments the NG count by "1". Here, the initial value of the NG count is "0".

[0065] The ECU 10 that has completed the process of step S17 proceeds to step S18, and the abnormality handling unit 105 determines whether the total value of the NG count is equal to or greater than the threshold. This threshold is a natural number of 2 or more. The threshold is recorded in the ROM 10B or the storage 10D.

[0066] When it is determined as "Yes" in step S18, the ECU 10 proceeds to step S19. The exception handling unit 105 that proceeds to step S19 prohibits access to the public API 21 by the non-genuine APP 30 determined as "Yes" in step S18 for a specified time. The exception handling unit 105 determines whether the specified time has elapsed based on the information obtained from the above timer.

[0067] The ECU 10 that has completed the process of step S19 proceeds to step S20, and the exception handling unit 105 sets the total value of the NG counts to "0".

[0068] When the second determination unit 103 determines as "No" in step S15, the ECU 10 proceeds to step S21. The exception handling unit 105 that proceeds to step S21 uninstalls the non-genuine APP 30 determined as "No" in step S15 from the ECU 10.

[0069] When the processing in step S16, S20, or S21 ends, or when it is determined as "No" in step S10 or S18, the ECU 10 temporarily ends the flowchart processing.

[0070] (Function and Effect)

[0071] Next, the function and effect of the present embodiment will be described.

[0072] The correspondence list 25 of the ECU 10 in the present embodiment stipulates rules for representing the correspondence between each non-genuine APP 30 and the allowed API 21 to which each non-genuine APP 30 is allowed access. Moreover, the first determination unit 101 implemented by the first middleware MW1 monitors the access actions 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 stipulated by the correspondence list 25 are simpler than the rules that define all the processes (behaviors) of all the non-genuine APPs 30. Therefore, the ECU 10 in the present embodiment can monitor the access actions of the non-genuine APP 30 to each data recorded in the public data recording unit 20 based on simple rules. Therefore, the computational load involved in the ECU 10 does not increase. Therefore, it is not necessary to use an expensive hardware structure to construct the ECU 10.

[0073] Also, in the ECU 10, the second determination unit 103 implemented by the second middleware MW2 monitors the access actions of the non-genuine APP 30 determined by the first determination unit 101 to have accessed the allowed API to the data recorded in the public data recording unit 20. In this way, since the access of the non-genuine APP 30 to the public data recording unit 20 is monitored twice, it is possible to determine with high accuracy whether the target API 21 accessed by the non-genuine APP 30 is the allowed API 21.

[0074] Further, in the ECU 10, the first determination unit 101 monitors the access actions of the non-genuine APP 30 to the data recorded in the public data recording unit 20. Therefore, compared with the case where the ECU 10 does not include the first determination unit 101 and the first access control unit 102, the computational load in the public data management area AR2 of the ECU 10 is less likely to increase.

[0075] Also, the frequency list 27 defines frequency conditions indicating the relationship between each public API 21 and the access frequency set for each public API 21. Further, when the second determination unit 103 determines that the access frequency of the non-genuine APP 30 to the permitted API 21 does not satisfy the frequency conditions, 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 conditions determined by the frequency list 27 are simpler than the rules defining all processes of all non-genuine APPs 30. Therefore, the ECU 10 can monitor the access actions of the non-genuine APP 30 to the respective data recorded in the public data recording unit 20 based on simple rules.

[0076] Also, in step S15, the non-genuine APP 30 that has been determined by the second determination unit 103 to have accessed a public API 21 that is not a permitted API is an application that should be prohibited by the first determination unit 101 from accessing the first operating system OS1, the hypervisor HV, the second operating system OS2, and the second middleware MW2. Nevertheless, this non-genuine APP 30 also attempts to access the first operating system OS1, the hypervisor HV, the second operating system OS2, and the second middleware MW2 by passing the check of the first determination unit 101. Therefore, it can be considered that the access of this non-genuine APP 30 to the public API 21 is a highly dangerous illegal access. Accordingly, the abnormality handling unit 105 uninstalls this non-genuine APP 30 from the ECU 10. Thereby, the ECU 10 can be protected from the non-genuine APP 30 that may perform highly dangerous attacks.

[0077] The risk level of the illegal access actions of the non-genuine APP 30 determined to be "no" by the first determination unit 101 in steps S11 and 12 and the non-genuine APP 30 determined to be "no" by the second determination unit 103 in step S14 is lower than the risk level of the illegal access actions of the non-genuine APP 30 determined to be "no" in step S15. Therefore, in the present embodiment, such non-genuine APPs 30 are not uninstalled from the ECU 10. That is, the non-genuine APP 30 that has repeated the above-described illegal access actions more than the above threshold is prohibited by the abnormality handling unit 105 from accessing the public API 21 for a specified time.

[0078] Further, the open data recording unit 20 records data related to physical quantities obtained by the genuine APP 34 and changing in linkage with at least one of the running, steering operation, and braking of the vehicle 12. In the present embodiment, unauthorized access to this data by non-genuine APPs 30 can be prevented. Therefore, there is little concern that non-genuine APPs 30 that have illegally obtained this data will execute control based on this data.

[0079] As described above, the ECU 10 according to the present embodiment has been described, but the design of the ECU 10 can be appropriately changed without departing from the gist of the present disclosure.

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

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

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

[0083] 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 open data management area AR2 may be local APIs. Alternatively, all applications installed in the non-trusted area AR1 may be applications made by a third party, and all APIs in the non-trusted area AR1 and the open data management area AR2 may be open APIs.

[0084] The abnormality handling unit 105 may monitor the operation status of at least one of the first operating system OS1 and the first middleware MW1 based on the system log recorded by at least one of the first operating system OS1 and the first middleware MW1. And when it is determined based on this operation status that at least one of the first operating system OS1 and the first middleware MW1 executes an illegal process, the abnormality handling unit 105 may temporarily stop the operation of the entire non-trusted area AR1.

[0085] 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 to record information related to the correspondence between the non-genuine APP 30 and the open API 21 (permitted API).

[0086] The number of applications installed in the non-reliable area AR1 and the number of applications installed in the control area AR3 can be arbitrary. Additionally, the number of APIs in the non-reliable area AR1 and the public data management area AR2 can be arbitrary.

[0087] In the public data recording unit 20, data of different types from the data related to the physical quantity that changes in association with at least one of the traveling, steering operation, and braking of the vehicle can be recorded.

Claims

1. An in-vehicle information processing device, wherein, Comprising: A processor that reads and executes a virtual machine monitor, a first operating system and a second operating system that operate independently on the virtual machine monitor, and at least one first application that operates on the first operating system; A first recording unit that records multiple types of data that the first application can access via the virtual machine monitor and the second operating system; And A second recording unit that records a correspondence list that specifies the correspondence between each of the first applications and the data, i.e., permitted data, that each of the first applications is permitted to access; The processor determines whether the data, i.e., the target data, that the first application attempts to access is the permitted data based on the correspondence list; When the processor determines that the target data is the permitted data, the processor permits the first application to access the target data, and when the processor determines that the target data is not the permitted data, the processor does not permit the first application to access the target data; A first middleware operating on the first operating system implements at least one application programming interface, i.e., API; Each of the first applications operates on the first middleware; The correspondence list specifies the correspondence between each of the first applications and the permitted APIs among the APIs that each of the first applications is permitted to access and through which the permitted data can be obtained by accessing through each of the first applications; When the processor determines, by executing the first middleware, that the first application has accessed at least one of the APIs, i.e., the target API, the processor determines whether the target API is the permitted API based on the correspondence list; The processor permits the first application that the processor determines, by executing the first middleware, to have accessed the permitted API to access the second operating system via the first operating system and the virtual machine monitor; A second middleware operating on the second operating system implements at least one of the APIs; The processor determines whether the target API accessed by the first application that the processor determines, by executing the second middleware, to have accessed the permitted API is the permitted API based on the correspondence list; When the processor determines, by executing the second middleware, that the target API is the permitted API, the processor permits the first application to access the permitted data.

2. The in-vehicle information processing device according to claim 1, wherein The in-vehicle information processing device includes a third recording unit that records a frequency list that specifies conditions, i.e., frequency conditions, related to the access frequency of the first application to the permitted API; When the processor determines that the access frequency of the first application to the permitted API does not meet the frequency conditions, the processor does not permit the first application to access the permitted data.

3. The in-vehicle information processing device according to claim 1 or 2, wherein The processor uninstalls the first application, which has accessed the target API determined by the processor as not being the permitted API by executing the second middleware, from the in-vehicle information processing device.

4. The vehicle-mounted information processing device according to claim 1 or 2, wherein: The data recorded in the first recording unit is data acquired by at least one second application running on a third operating system that runs independently of the first operating system and the second operating system on the virtual machine monitor.

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

6. An information processing method, wherein, The following processing is performed by a processor that reads and executes a virtual machine monitor, a first operating system and a second operating system that are independently operated on the virtual machine monitor, and at least one first application that is operated on the first operating system: When the first application attempts to access a recording unit recording a plurality of types of data via the virtual machine monitor and the second operating system, it is determined whether the data, i.e., the object data, that the first application attempts to access is the permitted data based on a correspondence list that specifies a correspondence between the first application and the data, i.e., the permitted data, that each first application is permitted to access. When it is determined that the object data is the permission data, the first application is permitted to access the object data, and when it is determined that the object data is not the permission data, the first application is not permitted to access the object data, The first middleware operating on the first operating system implements at least one application programming interface (API). Each of the first applications operates on the first middleware. The correspondence list defines a correspondence between each of the first applications and an allowed API, among the APIs that each of the first applications is allowed to access, that can obtain the allowed data by accessing the first applications. When the processor determines that the first application has accessed at least one of the APIs, namely, the target API, by executing the first middleware, the processor determines whether the target API is the permitted API based on the correspondence list. the processor permits the first application, which is determined by the processor to have accessed the permitted API by executing the first middleware, to access the second operating system via the first operating system and the virtual machine monitor, The second middleware operating on the second operating system implements at least one of the APIs. the processor determines, based on the correspondence list, whether the target API accessed by the first application determined by the processor to have accessed the permitted API by executing the second middleware is the permitted API, When the processor determines that the target API is the permitted API by executing the second middleware, the processor permits the first application to access the permitted data.

7. A storage medium storing a program readable by a computer, wherein the program includes: a virtual machine monitor; a first operating system and a second operating system that operate independently of each other on the virtual machine monitor; and at least one first application that operates on the first operating system and can access multiple types of data via the virtual machine monitor and the second operating system, when the program is executed by a processor, the following steps are performed: when the first application attempts to access a record section storing multiple types of data via the virtual machine monitor and the second operating system, a step of determining whether the data to be accessed by the first application, i.e., the target data, is the permitted data based on a correspondence list that defines the correspondence between the first application and the permitted data, i.e., the permitted data, that each first application is permitted to access; and a step of permitting the first application to access the target data when it is determined that the target data is the permitted data, and not permitting the first application to access the target data when it is determined that the target data is not the permitted data, a first middleware operating on the first operating system implements at least one application programming interface, i.e., API, each of the first applications operates on the first middleware, the correspondence list defines the correspondence between each first application and the permitted API among the APIs that each first application is permitted to access, and the permitted data can be obtained by accessing each permitted API by each first application, when it is determined by executing the first middleware that the first application has accessed at least one of the APIs, i.e., the target API, determining whether the target API is the permitted API based on the correspondence list, permitting the first application that is determined to have accessed the permitted API by executing the first middleware to access the second operating system via the first operating system and the virtual machine monitor, a second middleware operating on the second operating system implements at least one of the APIs, determining whether the target API accessed by the first application that is determined to have accessed the permitted API by executing the second middleware is the permitted API based on the correspondence list, when it is determined by executing the second middleware that the target API is the permitted API, permitting the first application to access the permitted data.

Images