Vehicle security device, security method, and program

Abstract

To provide a vehicle security device capable of suppressing processing concentration and security deterioration, and introducing Zero Trust Architecture, etc.SOLUTION: A vehicle security device is provided in an ECU of a vehicle, and comprises a proactive authentication unit 300 and a connection management unit 200. When an access request is made from any access source in the vehicle to any access destination in the vehicle, the proactive authentication unit determines whether to perform approval determination for the access request in a reactive authentication unit 420 of a zone ECU 400 connected to an access destination of the access request on the basis of the application reliability of the access source based on at least one of the application state of the access source and the vehicle state. When it is determined that approval determination is performed in the reactive authentication unit 420 corresponding to the access destination, the connection management unit outputs the access request to the zone ECU 400 of the access destination.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present disclosure relates to a vehicle security device, a security method, and a program installed in a vehicle. [Background technology]

[0002] In the field of IT (Information Technology) systems, boundary security, which applies security measures intensively to the boundary between an internal network and an external network, has been mainstream, but the limitations of boundary security have been pointed out, and the idea of ​​zero trust security, which is based on the idea of ​​not trusting the access source in principle, has been introduced. An authorization system for access requests that incorporates the idea of ​​zero trust security is being considered. For example, Patent Document 1 discloses a dynamic access authorization system that realizes dynamic authorization of access requests to resources. [Prior art documents] [Patent documents]

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

[0004] In recent years, security risks in vehicles have increased due to factors such as the spread of electric vehicles, and the introduction of so-called Zero Trust Architecture (ZTA) is being considered. However, if ZTA is applied directly to vehicles, authorization decision processing will be concentrated in the integrated ECU (Central ECU), raising concerns about real-time driving performance and load. It is also desirable to introduce ZTA in vehicles while suppressing security degradation.

[0005] Therefore, the present disclosure provides a vehicle security device, a security method, and a program that can introduce a zero trust architecture while suppressing processing concentration and security degradation. [Means for solving the problem]

[0006] A vehicle security device according to one embodiment of the present disclosure is a vehicle security device mounted on a vehicle, the vehicle having an ECU (Electronic Control Unit) in which the vehicle security device is installed, and a zone ECU that is managed by the ECU and controls equipment mounted on the vehicle, and the vehicle security device is equipped with a primary dynamic authentication unit that, when an access request is made from an arbitrary access source in the vehicle to an arbitrary access destination in the vehicle, determines whether or not to cause a secondary dynamic authentication unit of the zone ECU connected to the access destination of the access request to execute an authorization decision for the access request based on information about the application of the access source and a reliability of the application of the access source based on at least one of information about the application of the access source and the state of the vehicle, and a connection management unit that outputs the access request to the zone ECU of the access destination when it is determined that the authorization decision is to be executed in the secondary dynamic authentication unit corresponding to the access destination.

[0007] A security method according to one embodiment of the present disclosure is a security method executed by a vehicle security device mounted on a vehicle, the vehicle having an ECU (Electronic Control Unit) in which the vehicle security device is installed, and a zone ECU that is managed by the ECU and controls equipment mounted on the vehicle, and when there is an access request from an arbitrary access source in the vehicle to an arbitrary access destination in the vehicle, the security method determines whether or not to cause a secondary dynamic authentication unit of the zone ECU connected to the access destination of the access request to execute an authorization decision for the access request based on a reliability of the application of the access source which is based on at least one of a state of the application of the access source and a state of the vehicle, and when it is determined that the authorization decision should be executed in the secondary dynamic authentication unit corresponding to the access destination, outputs the access request to the zone ECU of the access destination.

[0008] A program according to one aspect of the present disclosure is a program for causing a computer to execute the above security method. Effect of the Invention

[0009] According to one aspect of the present disclosure, it is possible to realize a vehicle security device or the like that can introduce a zero trust architecture while suppressing processing concentration and security degradation. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a block diagram showing an example of a vehicle security system according to an embodiment. [Diagram 2] FIG. 2 is a block diagram illustrating a functional configuration of the integrated ECU according to the embodiment. [Diagram 3] FIG. 3 is a block diagram showing a functional configuration of the zone ECU according to the embodiment. [Figure 4] FIG. 4 is a flowchart showing a determination operation of the integrated ECU according to the embodiment. [Diagram 5] FIG. 5 is a flowchart illustrating an update operation of the determination information of the integrated ECU according to the embodiment. [Figure 6] FIG. 6 is a flowchart showing the determination operation of the zone ECU according to the embodiment. [Figure 7] FIG. 7 is a flowchart showing an update operation of the determination information of the zone ECU according to the embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, the embodiment will be specifically described with reference to the drawings.

[0012] The embodiments described below are all comprehensive or specific examples. The numerical values, shapes, materials, components, arrangement positions and connection forms of the components shown in the following embodiments are merely examples and are not intended to limit the present disclosure.

[0013] (Embodiment) Hereinafter, a vehicle security device according to an embodiment will be described.

[0014] [1. Vehicle security system configuration] 1 is a block diagram showing an example of a vehicle security system 1 according to the present embodiment. The vehicle security system 1 is mounted on a vehicle (an example of a moving body). For example, the vehicle security system 1 may include a primary dynamic authentication unit and a connection management unit, and one or more secondary dynamic authentication units and a connection management unit, and an integrated ECU (Electronic Control Unit) 100, zone ECUs 400, 500, 600, and 700, an actuator 901, and a sensor 902 provided in the vehicle may not be components of the vehicle security system 1.

[0015] The vehicle security system 1 is a system for applying a zero trust architecture to a vehicle. The zero trust architecture is, for example, the SP (Special Publication) 800-207 zero trust architecture by the NIST (National Institute of Standards and Technology). When the zero trust architecture is applied to a vehicle, authentication is dynamically performed for each of various resources (for each access request) possessed by the vehicle. In order to dynamically perform authentication of an access request, the vehicle security system 1 includes a primary dynamic authentication unit 300 and a connection management unit 200 provided in the integrated ECU 100, and one or more secondary dynamic authentication units 420, 520, 620, 720 (secondary dynamic authentication unit 420, etc.) and connection management units 410, 510, 610, 710 (connection management unit 410, etc.) provided in the zone ECUs 400, 500, 600, 700 (zone ECU 400, etc.). The primary dynamic authentication unit 300 and the secondary dynamic authentication unit 420, etc. are examples of a PDP (Policy Decision Point) in the zero trust architecture, and the connection management unit 200 and the connection management unit 410, etc. are examples of a PEP (Policy Enforcement Point) in the zero trust architecture.

[0016] In this way, the PDP and PEP are distributed in the vehicle security system 1. In the following, the secondary dynamic authentication unit provided in the zone ECU is also referred to as an edge PDP, and the connection management unit provided in the zone ECU is also referred to as an edge PEP. In addition, the access request includes a request to use a specific service, an access control request to control a specific resource, and the like.

[0017] 1 shows an integrated ECU 100 provided in a vehicle, a zone ECU 400 connected to the integrated ECU 100, and an actuator 901 and a sensor 902 connected to the zone ECU 500. In other words, the vehicle includes an ECU (the integrated ECU 100), a zone ECU 400, and the like.

[0018] The integrated ECU 100 is an ECU that controls the entire vehicle as a central ECU for the zone ECU 400 and the like. The integrated ECU 100 is an example of a vehicle security device mounted on a vehicle. The integrated ECU 100 is a central ECU that integrates multiple ECUs. The integrated ECU 100 is an ECU that integrates functions that were previously distributed across multiple ECUs in order to resolve issues of increased development time and costs that accompany the complexity of in-vehicle systems, and is an ECU that utilizes virtualization technology to operate multiple virtual computers (virtual machines: VMs) on one ECU.

[0019] The integrated ECU 100 includes a proactive authentication unit 300 and a connection management unit 200. The integrated ECU 100 is an example of an ECU in which the proactive authentication unit 300 and the connection management unit 200 are provided. The integrated ECU 100 further includes hardware 10, security software 20, a hypervisor 30, virtual machines 40, 50, and 60, a trust zone 70 (denoted as TZ in FIG. 1) in which the execution environment is secure, and an HSM (Hardware Security Module) 91 and a storage 92 which are examples of resources 90 (see FIG. 2) of the integrated ECU 100. The integrated ECU 100 is a computer including a processor (microprocessor) and a memory. The memory is a read only memory (ROM) and a random access memory (RAM), and can store a program executed by the processor.

[0020] In the integrated ECU 100, a security software 20, a hypervisor 30, and a trust zone 70 (TrustZone (trademark): trusted area) run on a system on chip (hereinafter, SoC) that is hardware 10, and a plurality of virtual machines 40, 50, and 60 run on the hypervisor 30, and different operating systems (hereinafter, OS) run on each of the virtual machines 40, 50, and 60, and an active authentication unit 300 runs in the trust zone 70. The hardware 10 represents a machine or device that can accept data, perform logical operations on data, store data, and display data, and may include, but is not limited to, a processor and a memory.

[0021] The security software 20 is security software that realizes a trust zone, and an example thereof is Secure Monitor, but is not limited to this.

[0022] The hypervisor 30 is software that serves as a virtualization platform for operating one or more virtual machines (a plurality of virtual machines in the example of FIG. 1). In this embodiment, a connection management unit 200, an anomaly detection unit 81 (an IDS (Intrusion Detection System) shown in FIG. 1), and a monitoring unit 82 (an RI (Runtime Integrity) shown in FIG. 1) operate within the hypervisor 30. The anomaly detection unit 81 detects anomalies in each virtual machine (e.g., each application). Details of the connection management unit 200 will be described later. In this specification, an application or a process is also referred to as a user.

[0023] The virtual machines 40, 50 and 60 run respective applications.

[0024] The virtual machine 40 includes an OS 41 and one or more applications ("Body," "ADAS (Advanced Driver Assistance System)," and "Charging Control" in FIG. 1). The OS 41 manages the execution of the applications. The OS 41 has an abnormality detection unit 42 that detects abnormalities in each application, and a monitoring unit 43 that monitors whether the abnormality detection unit 42 is normal or not. The monitoring unit 43 verifies that the monitored abnormality detection unit 42 is operating as expected (completeness of operation), even while the abnormality detection unit 42 is operating.

[0025] In this way, the virtual machine 40 has the functions (applications) of body control, ADAS, and charging control, and these functions (applications) are also realized by a processor or the like that executes a program stored in a memory.

[0026] The virtual machine 40 is an in-house virtual machine of a vehicle manufacturer.

[0027] The virtual machine 50 includes an OS and one or more applications ("IVI (In-Vehicle Infotainment) App 53" and "3rd App 52" in FIG. 1). The OS manages the execution of the applications. The OS has an anomaly detection unit (IDS in FIG. 1) that detects anomalies in each application, and a monitoring unit (RI in FIG. 1) that monitors whether the anomaly detection unit is normal or not.

[0028] In this way, the virtual machine 50 has an IVI control function (application) and a 3rd App 52 that runs in a 3rd Party area in the sandbox 51, and these functions (applications) are also realized by a processor that executes a program stored in a memory. Note that the "3rd App 52" refers to an application program (also called a 3rd Party app) of a provider that provides mobility services. The sandbox 51 is an area in which applications imported from outside the vehicle run.

[0029] The virtual machine 50 is an in-house virtual machine of the vehicle manufacturer.

[0030] The virtual machine 60 includes an OS and one or more applications ("App" in FIG. 1). The OS manages the execution of the applications.

[0031] In this way, the virtual machine 60 has IVI control functions (applications), but these functions (applications) are also realized by a processor or the like that executes programs stored in memory.

[0032] Each application may be assigned a certificate including an authority level. The authority level includes information about the authority of the application, such as information indicating whether or not a function related to human life, such as driving, stopping, turning, etc., can be accessed, and information indicating whether information can only be referenced or can be rewritten.

[0033] The active authentication unit 300 operates in a Trusted Execution Environment (TEE) such as the trust zone 70. The TEE operates independently of the normal OS provided in the virtual machines 40, 50, and 60. The active authentication unit 300 is realized by a processor that executes a program stored in a memory. Details of the active authentication unit 300 will be described later.

[0034] The zone ECU 400 and the like are arranged in a vehicle and control resources in the area in which they are arranged. The zone ECU 400 and the like are connected to, for example, devices mounted on the vehicle and control the devices through the connection. For example, the zone ECU 500 controls an actuator 901 and a sensor 902. The zone ECU 400 and the like are integrated by the integrated ECU 100. The devices include at least one of a terminal accelerator, an actuator 901, a sensor 902, a motor, a battery, and a charger.

[0035] The zone ECU 400, etc. is a computer including a processor (microprocessor) and a memory, etc. The memory is a ROM, a RAM, etc., and can store a program executed by the processor. For example, the function of the zone ECU 400, etc. to control resources (e.g., the actuator 901, the sensor 902, the charger, etc.) connected to the zone ECU 400, etc. is realized by the processor, etc., which executes a program stored in the memory.

[0036] At least one of the multiple zone ECUs includes a secondary dynamic authentication unit, which is an example of a PDP in the zero trust architecture, and a connection management unit, which is an example of a PEP in the zero trust architecture. In this embodiment, the zone ECU 400 includes the secondary dynamic authentication unit 420 and the connection management unit 410, the zone ECU 500 includes the secondary dynamic authentication unit 520 and the connection management unit 510, the zone ECU 600 includes the secondary dynamic authentication unit 620 and the connection management unit 610, and the zone ECU 700 includes the secondary dynamic authentication unit 720 and the connection management unit 710.

[0037] The number of zone ECUs mounted on a vehicle is not particularly limited as long as it is one or more.

[0038] The ECU 801 and the ECU 802 are connected to a communication path between the integrated ECU 100 and the zone ECUs.

[0039] Here, detailed configurations of the integrated ECU 100 and the zone ECU 400 will be described with reference to Fig. 2 and Fig. 3. First, detailed configurations of the integrated ECU 100 will be described with reference to Fig. 2. Fig. 2 is a block diagram showing a functional configuration of the integrated ECU 100 according to this embodiment. In Fig. 2, each application is illustrated as "App".

[0040] As shown in FIG. 2, the integrated ECU 100 includes an active authentication unit 300 and a connection management unit 200, which are essential parts.

[0041] When the primary dynamic authentication unit 300 determines that an authorization decision (authentication) should be made in the secondary dynamic authentication unit of a zone ECU connected to a resource that is the access destination of the access request, the connection management unit 200 outputs the access request to the secondary dynamic authentication unit corresponding to the access destination to make the secondary dynamic authentication unit corresponding to the access destination make the authorization decision. The connection management unit 200 includes a communication unit 210, an access control execution unit 220, an access request receiving unit 230, and a through process execution unit 240.

[0042] The communication unit 210 communicates with each component in the vehicle security system 1. The communication unit 210 also communicates with the active authentication unit 300. When the communication unit 210 receives an access request from an application, it transmits an access determination request from the access request receiving unit 230 to the active authentication unit 300. The communication unit 210 is configured to include a communication module (communication circuit).

[0043] When the access control determination unit 320 of the active authentication unit 300 determines that the received access request is to be executed, the access control execution unit 220 executes control according to the access request.

[0044] The access request receiving unit 230 receives an access request from each application via the communication unit 210. In the example of Fig. 2, the access request receiving unit 230 receives an access request from an IVI App 53. When the access request receiving unit 230 receives an access request, it transmits an access judgment request for the received access request to the primary dynamic authentication unit 300 via the communication unit 210, and receives the judgment result of the primary dynamic authentication unit 300, that is, authorization (access is permitted), refusal (access is not permitted), or pass-through processing (judgment is left to the secondary dynamic authentication unit 420). The access judgment request is a request to execute a judgment of whether to grant, deny, or pass-through processing for the received access request, and includes, for example, information indicating the access source.

[0045] The through process execution unit 240 executes the through process when the through process determination unit 340 of the active authentication unit 300 determines that the received access request is to be through processed. The through process is a process for making the zone ECU make an authorization decision for the access request, for example, a process for not making an authorization decision for the access request in the active authentication unit 300, but making the zone ECU that controls the access destination of the access request make an authorization decision for the access request. Specifically, the through process execution unit 240 transmits the access request for which the authorization decision has not been made in the active authentication unit 300 to the zone ECU that controls the access destination. For example, when the access destination is the actuator 901, the through process execution unit 240 transmits the access request from the IVI App 53 to the zone ECU 500 that controls the actuator 901. The through process execution unit 240 has a function of controlling a connection between an access source and an access destination, and connects the IVI App 53 and the zone ECU 500. The control includes connection and disconnection.

[0046] When the connection management unit 200 receives an access request (for example, an access request shown in FIG. 2) from an arbitrary access source in the vehicle to an arbitrary access destination in the vehicle, the active dynamic authentication unit 300 determines whether the authorization decision of the access request (specifically, the decision as to whether the access request is permissible or not) is made by the own device (the active dynamic authentication unit 300) or by the secondary dynamic authentication unit of the zone ECU corresponding to the access destination, based on the reliability of the application of the access source. If the active dynamic authentication unit 300 determines that the active dynamic authentication unit 300 will make the authorization decision, the active dynamic authentication unit 300 dynamically makes the authorization decision of the access request, and if the secondary dynamic authentication unit determines that the secondary dynamic authentication unit will make the authorization decision, the active dynamic authentication unit 300 does not make the authorization decision of the access request. As a result, if it is determined that the secondary dynamic authentication unit will make the authorization decision, the active dynamic authentication unit 300 does not make the authorization decision, so that it is possible to prevent the determination process from concentrating on the active dynamic authentication unit 300. The active dynamic authentication unit 300 may also acquire the reliability of the application of the access source based on the state of the vehicle. The calculation of the reliability will be described later.

[0047] The active dynamic authentication unit 300 includes a communication unit 310, an access control determination unit 320, a vehicle status collection unit 330, a through processing determination unit 340, a permission list memory unit 350, a permission list update unit 360, a permission list synchronization unit 370, a reliability information generation unit 380, a reliability information memory unit 391, and a dynamic authentication distributed deployment information memory unit 392.

[0048] The communication unit 310 communicates with the connection management unit 200. The communication unit 310 includes a communication module (communication circuit).

[0049] When the through process determination unit 340 determines that the access request authorization determination is to be performed by the device itself, the access control determination unit 320 performs the authorization determination of the access request. The authorization determination of the access request is performed based on the permission list, and the permission list describes which access source is permitted to which access destination when the vehicle is in a certain state. It can also be said that the permission list describes which resource (access source) is permitted to which access destination under what conditions. The permission list may include a determination set by default in the case of an undefined application. The determination set by default may include, for example, a total prohibition (total no access is permitted) or a minimum privilege (only the minimum access is permitted). The permission list is also called a policy.

[0050] For example, the access control determining unit 320 determines to permit access to the access destination (resource of the access destination) of the access request only when the vehicle state satisfies the conditions in the permission list.

[0051] The access control determining unit 320 may read out from the permission list storage unit 350 a permission list corresponding to the resource to be accessed by the access request, from among a plurality of permission lists, and make an authorization determination for the access request.

[0052] The vehicle state collection unit 330 acquires vehicle state information indicating the state of the vehicle via the communication unit 310. When the vehicle state collection unit 330 acquires the vehicle state information, for example, an access request to a resource holding the vehicle state information is authenticated, and the vehicle state information may be acquired via the connection management unit 200.

[0053] For example, an access request made by a resource in a vehicle may or may not be permitted depending on the state of the vehicle, so whether or not to permit the access request is determined taking into account the state of the vehicle. Therefore, vehicle state information is collected by the vehicle state collection unit 330. Note that the state of the vehicle includes, for example, the usage state of the access destination, the running state of the vehicle, the security state of the access source, the security state of the access destination, the usage state of the service used in the vehicle, or the state of the access destination.

[0054] The through-processing determination unit 340 determines whether to perform through-processing of an access request received by the connection management unit 200 based on the reliability of the access source. Although details will be described later, the through-processing determination unit 340 determines to perform through-processing when the reliability is equal to or higher than a predetermined level, that is, when the access source is reliable. In other words, the authorization decision for an access request from an access source with a high reliability is made by the zone ECU, not by the integrated ECU 100.

[0055] The permission list storage unit 350 is a storage device that stores the permission list. The permission list may be stored for each resource. The permission list storage unit 350 is realized by, for example, a hard disk drive (HDD) or a semiconductor memory.

[0056] When an allowance list update event occurs, the allowance list update unit 360 updates the allowance list stored in the allowance list storage unit 350. The allowance list update event may be, for example, acquisition of a new allowance list from outside via OTA (Over The Air), or occurrence of a predetermined timing.

[0057] The permission list synchronization unit 370 performs processing to synchronize the contents of the permission list stored in the active authentication unit 300 with the contents of the permission list stored in each zone ECU. The permission list synchronization unit 370 copies the permission list stored in the permission list storage unit 350 (e.g., the latest permission list) and transmits it to each zone ECU.

[0058] The reliability information generating unit 380 generates reliability information including reliability based on at least one of information related to the application and the state of the vehicle, and stores the generated reliability information in the reliability information storage unit 391. The reliability information generating unit 380 sets the reliability for each application.

[0059] The reliability information generating unit 380 may generate the reliability of an application based on the placement of the application (on which virtual machine the application is provided). The reliability information generating unit 380 may set different reliability levels based on whether the virtual machine is in-house or externally procured, for example. For example, when the virtual machine is in-house, the reliability information generating unit 380 may set a higher reliability level than when the virtual machine is externally procured. When the virtual machine 40 is in-house and the virtual machine 60 is externally procured, the reliability information generating unit 380 may set a first reliability level of the body, ADAS, and charging control applications higher than a second reliability level of the App (application) of the virtual machine 60. In addition, the reliability information generating unit 380 may set a second reliability level for an application provided in the sandbox 51 of the in-house virtual machine, or may set a reliability level higher than the second reliability level and lower than the first reliability level. In FIG. 1, applications with low reliability are indicated by diagonal hatching.

[0060] The reliability information generating unit 380 may set the reliability based on a certificate including an authority level (permission level) acquired from an access source application. For example, the higher the authority level for a function related to human life, the higher the reliability may be set. For example, a higher reliability may be set for an application capable of controlling driving than for an application capable of referring to information in the storage 92.

[0061] In this manner, the trust information generating unit 380 may set the trust level of an application based on information about the application that can be obtained in advance, such as the placement of the application and the authority level of the application.

[0062] Furthermore, the reliability information generating unit 380 may set the reliability based on the detection result of an anomaly detecting unit mounted on the vehicle. When the anomaly detecting unit detects an anomaly in an application or an anomaly in a place where the application is installed (e.g., a virtual machine), the reliability information generating unit 380 may set the reliability of the application lower than when the anomaly is not detected. It can also be said that when an anomaly is detected, the reliability information generating unit 380 revokes the authority of the application (lowers the authority level).

[0063] Furthermore, the reliability information generating unit 380 may set the reliability based on the monitoring result (complete verification result) of the monitoring unit. When the monitoring unit detects an abnormality in an anomaly detection unit that monitors an application or an abnormality in an anomaly detection unit that monitors a location where the application is installed (for example, a virtual machine), the reliability information generating unit 380 may set the reliability of the application to be lower than when the abnormality is not detected.

[0064] An abnormality in an application, an abnormality in the location where the application is installed, an abnormality in the abnormality detection unit that monitors the application, and an abnormality in the abnormality detection unit that monitors the location where the application is installed are examples of information related to an application.

[0065] In this way, the reliability information generating unit 380 may set the reliability of an application based on a dynamically changing state of the application, such as an abnormality related to the application. Note that the reliability may be set based on the presence or absence of an abnormality at the current time, or based on the presence or absence of an abnormality or the number of abnormalities during a predetermined period of time in the past including the current time.

[0066] Furthermore, the reliability information generating unit 380 may set the reliability of the application based on the vehicle state, such as the vehicle's driving state, the vehicle's driving position, etc. When the vehicle's driving state is more dangerous (e.g., a state in which the vehicle is driving at high speed) or the vehicle's driving position is more dangerous (e.g., the vehicle is located on a highway), the reliability information generating unit 380 may set the reliability lower than when this is not the case.

[0067] The reliability information generating unit 380 may calculate two or more of the reliability levels described above, and calculate one reliability level by performing an averaging operation or the like based on the two or more calculated reliability levels.

[0068] The reliability information storage unit 391 is a storage device that stores the reliability information generated by the reliability information generation unit 380. The reliability information storage unit 391 is realized by, for example, an HDD or a semiconductor memory.

[0069] The dynamic authentication distributed arrangement information storage unit 392 stores dynamic authentication distributed arrangement information indicating whether or not each of one or more zone ECUs mounted on the vehicle has a sub dynamic authentication unit and a connection management unit. The dynamic authentication distributed arrangement information storage unit 392 is realized by, for example, a HDD or a semiconductor memory. The dynamic authentication distributed arrangement information is an example of authentication feasibility information.

[0070] Next, a detailed configuration of zone ECU 400 will be described with reference to Fig. 3. Fig. 3 is a block diagram showing the functional configuration of zone ECU 400 according to this embodiment. Note that zone ECUs 500, 600, and 700 have the same configuration as zone ECU 400, and therefore their description will be omitted.

[0071] 3, the zone ECU 400 includes a connection management unit 410, which is a main part, and a secondary dynamic authentication unit 420. In this manner, in the vehicle security system 1 according to the present embodiment, the zone ECU is also provided with a dynamic authentication unit (e.g., secondary dynamic authentication unit 420). The connection management unit 410 may be provided, for example, in a normal area 401 (an area that is not a secure area) in the zone ECU 400, and the secondary dynamic authentication unit 420 may be provided, for example, in a trusted area 402 (a secure area) in the zone ECU 400.

[0072] The connection management unit 410 is provided on a communication path between an access source and an access destination (for example, the integrated ECU 100 and the access destination), and controls the connection between the access source and the access destination according to the determination of the secondary dynamic authentication unit 420. The connection management unit 410 outputs an access request for which authorization determination has not been performed (pass-through processing) from the integrated ECU 100 to the access destination according to the determination of the secondary dynamic authentication unit 420, or controls not to output the access request to the access destination (controls the connection between the access source and the access destination). When the secondary dynamic authentication unit 420 determines that the access request is to be output (authorized), the connection management unit 410 outputs the access request to the resource of the access destination, and when the secondary dynamic authentication unit 420 determines that the access request is not to be output (not authorized), the connection management unit 410 does not output the access request to the resource of the access destination. The connection management unit 410 includes a communication unit 411, an access control execution unit 412, and an access request receiving unit 413. The connection management unit 410 has a configuration that does not include the pass-through processing execution unit 240 among the components of the connection management unit 200.

[0073] The communication unit 411 communicates with the integrated ECU 100 and the sub dynamic authentication unit 420. The communication unit 411 may also be capable of communicating with at least one of the ECU 801 and the ECU 802. When the communication unit 411 is capable of communicating with at least one of the ECU 801 and the ECU 802, the communication unit 411 acquires an access request from the at least one of the ECUs without going through the integrated ECU 100. The communication unit 411 is configured to include a communication module (communication circuit).

[0074] When the access control determination unit 422 of the secondary dynamic authentication unit 420 determines that the received access request is to be executed, the access control execution unit 412 executes control according to the access request.

[0075] The access request receiving unit 413 receives an access request from each application via the communication unit 411 .

[0076] When the connection management unit 410 receives an access request from an access source in the vehicle to an access destination in the vehicle (for example, an access request shown in FIG. 3) that has not been subjected to an authorization decision in the integrated ECU 100, the secondary dynamic authentication unit 420 dynamically performs an authorization decision for the access request. It can also be said that the secondary dynamic authentication unit 420 dynamically performs an authorization decision for an access request from an access source with high reliability. The secondary dynamic authentication unit 420 includes a communication unit 421, an access control determination unit 422, a vehicle state collection unit 423, an authorization list storage unit 424, an authorization list update unit 425, and an authorization list synchronization unit 426.

[0077] The communication unit 421 communicates with the connection management unit 410. The communication unit 421 includes a communication module (communication circuit).

[0078] The access control determination unit 422 performs an authorization determination for an access request for which an authorization determination has not been made (a request that has been passed through) from the integrated ECU 100. The method of determining authorization for an access request is not particularly limited, and may be the same as that of the access control determination unit 320.

[0079] The vehicle state collection unit 423 acquires vehicle state information indicating the state of the vehicle via the communication unit 421 .

[0080] The permission list storage unit 424 is a storage device that stores the permission list. The permission list stored in the permission list storage unit 424 is the permission list output from the permission list synchronization unit 370 (i.e., output from the integrated ECU 100), and is the same as the permission list stored in the permission list storage unit 350. The permission list storage unit 424 is realized by, for example, a HDD or a semiconductor memory.

[0081] The permission list update unit 425 updates the permission list stored in the permission list storage unit 424 when a permission list update event occurs.

[0082] The permission list synchronization unit 426 performs processing to make the permission list stored in the secondary dynamic authentication unit 420 the same as the permission list stored in the primary dynamic authentication unit 300. When a permission list update event occurs, the permission list synchronization unit 426 outputs a request to distribute the latest permission list to the integrated ECU 100. Even when the permission list synchronization unit 426 makes a request to distribute the permission list, authentication for the permission list distribution request may be performed, and the permission list may be acquired via the connection management unit 410.

[0083] [2. Operation of vehicle security system] Next, the operation of the vehicle security system 1 configured as above will be described with reference to Figures 4 to 7. Figure 4 is a flowchart showing the determination operation (security method) of the integrated ECU 100 according to this embodiment.

[0084] As shown in FIG. 4, the communication unit 310 of the active authentication unit 300 acquires, via the communication unit 210, an access judgment request corresponding to an access request sent from any application (user) and received by the access request receiving unit 230 (S11).

[0085] Next, the through process determination unit 340 determines whether the access request destination is a zone ECU and whether the zone ECU has an edge PDP / PEP (S12). Based on the dynamic authentication distributed arrangement information from the dynamic authentication distributed arrangement information storage unit 392, the through process determination unit 340 determines whether the access destination resource of the access request is a resource of the integrated ECU 100 or a zone ECU, and if it is determined that the access destination resource of the access request is a zone ECU, it further determines whether the zone ECU (target zone ECU) that controls the access destination resource has a secondary dynamic authentication unit and a connection management unit (edge ​​PDP and edge PEP). If the dynamic authentication distributed arrangement information includes information indicating that the target zone ECU has a secondary dynamic authentication unit and a connection management unit, the through process determination unit 340 determines that the target zone ECU has a secondary dynamic authentication unit and a connection management unit. If it is known that the target zone ECU has a secondary dynamic authentication unit and a connection management unit (for example, if all zone ECUs have a secondary dynamic authentication unit and a connection management unit), the process of determining whether or not an edge PDP and an edge PEP are present in step S12 may be omitted. Also, it is determined whether or not an access request is an access request to a resource of the integrated ECU 100, and if it is an access request to a resource of the integrated ECU 100, the process of determining whether or not an edge PDP and an edge PEP are present in step S12 may be omitted. An access request determined as Yes in step S12 can also be said to be an access request to a zone ECU.

[0086] Next, when the through process determination unit 340 determines that the access request destination is a zone ECU and that the target zone ECU has a secondary dynamic authentication unit and a connection management unit (Yes in S12), it further determines whether the security state of the vehicle is normal or not based on the vehicle state acquired by the vehicle state collection unit 330 (S13). The through process determination unit 340 determines that the security state of the vehicle is abnormal if any of the anomaly detection units mounted on the vehicle detects an abnormality and if the vehicle is traveling dangerously, such as at high speed. In other words, the through process determination unit 340 determines that the security state of the vehicle is normal if no abnormality is detected by any of the anomaly detection units mounted on the vehicle and if the vehicle is traveling safely.

[0087] Next, when the pass-through process determination unit 340 determines that the security state of the vehicle is normal (Yes in S13), it further determines whether it is time for a double check (S14). A double check means that the primary dynamic authentication unit 300 and the secondary dynamic authentication unit 420 each perform an authorization determination for an access request. The pass-through process determination unit 340 determines that it is time for a double check when, for example, a predetermined condition is met: it is the first access since the reliability or permission list was updated; a certain period of time has passed since the previous double check; or the number of access requests obtained since the double check exceeds a certain number (an example of when it is time to perform a double check); or when a trigger is received from outside the vehicle (for example, an instruction from a monitoring center that monitors the vehicle). The predetermined condition may include at least one of: an abnormality is detected in the vehicle; the vehicle is traveling at high speed; and it is time to perform an authorization determination in each of the primary dynamic authentication unit 300 and the secondary dynamic authentication unit 420.

[0088] Next, if the pass-through process determination unit 340 determines that it is not time for double checking (No in S14), it acquires reliability information of the access source application from the reliability information storage unit 391 (S15). The reliability information acquired here is part of the information used in the determination process executed in step S19 described later.

[0089] Next, the through process determination unit 340 determines whether the reliability included in the acquired reliability information is equal to or greater than a threshold (S16). That is, the through process determination unit 340 determines whether the reliability of the access source is high. In this way, in step S16, a part of the information used in the process of step S19 is used in advance to make the determination.

[0090] Next, if the reliability of the access source application is equal to or higher than the threshold (Yes in S16), the through process determination unit 340 executes the through process (S17). The through process execution unit 240 outputs the access request to the target zone ECU based on the determination result of the through process determination unit 340. That is, the through process is executed only when the reliability of the access source application is high. Note that the through process determination unit 340 may add information indicating that the through process has been executed to the access request to be subjected to the through process, and output the access request to the target zone ECU.

[0091] In addition, if the through processing determination unit 340 determines No in steps S12, S13, and S16, and if the through processing determination unit 340 determines Yes in step S15, the access control determination unit 320 performs an authorization determination on its own device (active authentication unit 300), and therefore obtains the permission list to be used for the authorization determination by having the permission list storage unit 350 read it out (S18).

[0092] Next, the access control determination unit 320 executes a determination process for making an authorization determination for the access request based on the permission list (S19). If the access control determination unit 320 has normally determined the authorization of the access request (no authentication error has occurred), the access control execution unit 220 executes processing for the access request.

[0093] By the above processing, the zone ECU performs the judgment processing only when the reliability is high, so that the processing load of the authorization judgment can be distributed (i.e., the processing load of the integrated ECU 100 can be reduced) while suppressing a decrease in security in the vehicle security system 1.

[0094] It should be noted that the permission list is not used in the determinations in steps S12, S13, S14 and S16.

[0095] If the determination in step S14 is Yes, a double check is performed on the access request. If the determination in step S14 is Yes, the access control determination unit 320 executes a determination process in step S30, and the through process execution unit 240 may output the access request to which information indicating that it is a target for double check is added to the target zone ECU. Furthermore, the zone ECU that has acquired the access request to which information indicating that it is a target for double check is added may execute a determination process shown in FIG. 6 (to be described later) on the access request (S45), and output the execution result (authentication result) to the active authentication unit 300. Then, if the respective execution results of the active authentication unit 300 and the zone ECU match, the access control execution unit 220 may be caused to execute control according to the access request.

[0096] Next, an update operation of the determination information of the integrated ECU 100 will be described with reference to Fig. 5. Fig. 5 is a flowchart showing an update operation (security method) of the determination information of the integrated ECU 100 according to this embodiment.

[0097] 5, the reliability information generating unit 380 of the active authentication unit 300 judges whether or not a reliability update event has occurred (S31). The reliability update event here includes at least one of the following: firmware has been updated, a new reliability has been obtained from the outside via OTA, a new application has been downloaded, an anomaly has been detected by the anomaly detection unit, and a predetermined timing has occurred.

[0098] Next, if the reliability information generating unit 380 determines that a reliability update event has occurred (Yes in S31), it proceeds to step S32, and if it determines that a reliability update event has not occurred (No in S31), it proceeds to step S33.

[0099] Next, when it is determined that a reliability update event has occurred, the reliability information generating unit 380 updates the reliability in accordance with the reliability update event (S32).

[0100] Next, the permission list update unit 360 determines whether or not a permission list update event has occurred (S33). The permission list update event here includes at least one of the following: the active authentication unit 300 has determined that the permission list needs to be updated; a zone ECU has requested the integrated ECU 100 for the latest permission list; and a certain period of time has passed since the previous update.

[0101] If the allowance list update unit 360 determines that an allowance list update event has occurred (Yes in S33), the process proceeds to step S34, and if it determines that an allowance list update event has not occurred (No in S33), the process proceeds to step S36.

[0102] Next, when the allowance list update unit 360 determines that an allowance list update event has occurred, it updates the allowance list stored in the allowance list storage unit 350 in accordance with the allowance list update event (S34).

[0103] Next, the permission list synchronization unit 370 distributes the updated permission list (S35). The permission list synchronization unit 370 copies the updated permission list and outputs it to all zone ECUs via the communication units 310 and 210. This makes it possible for the integrated ECU 100 and the zone ECUs to have the same permission list. In other words, the contents of the permission lists held by the integrated ECU 100 and the zone ECUs can be synchronized.

[0104] Next, the reliability information generating unit 380 judges whether or not to continue the process of updating at least one of the reliability and the permission list (S36). If the reliability information generating unit 380 judges that the update process should be continued (Yes in S36), it returns to step S31 and continues the process, and if it judges that the update process should not be continued (No in S36), it ends the process.

[0105] Note that the process of updating the trustworthiness (S31 and S32) and the process of updating the permission list (S33 to S35) are not limited to being executed in this order. Furthermore, the process of updating the trustworthiness and the process of updating the permission list may be executed at timings independent of each other.

[0106] Next, an update operation of the determination information of the zone ECU will be described with reference to Fig. 6. Fig. 6 is a flowchart showing the determination operation (vehicle security method) of the zone ECU according to this embodiment. In the following, a case where the target zone ECU is zone ECU 400 will be described.

[0107] 6, the communication unit 421 of the secondary dynamic authentication unit 420 acquires, via the communication unit 411 (S41), an access determination request corresponding to the access request output from the integrated ECU 100 and received by the access request receiving unit 413 (i.e., an access determination request corresponding to the access request from the application acquired in step S11). Here, it is assumed that the access request acquired in step S41 is an access request that has been passed through. Note that whether or not the access request is a passed through access request can be determined based on whether or not information indicating that the access request has been passed through is added to the access request.

[0108] Next, the permission list synchronization unit 426 judges whether it is time to synchronize the permission list (S42). The permission list synchronization unit 426 judges that it is time to synchronize the permission list when, for example, it is the first access since the reliability information or the permission list was updated, when a certain period of time has passed since the last update or a certain number of access requests have been received, or when a trigger has been received from outside the vehicle (for example, an instruction from a monitoring center that monitors the vehicle).

[0109] Next, if the permission list synchronization unit 426 determines that it is the permission list synchronization timing (Yes in S42), it executes permission list synchronization processing (S43), and if it determines that it is not the permission list synchronization timing (No in S42), it proceeds to step S44. The synchronization processing in step S43 includes processing in which the permission list synchronization unit 426 transmits a request to the integrated ECU 100 to distribute the latest permission list (processing for possessing a common permission list).

[0110] Next, the permission list synchronization unit 426 acquires the latest permission list from the active authentication unit 300 via the communication unit 421 (S44). The acquired permission list is stored in the permission list storage unit 424 by the permission list update unit 425. In other words, the permission list stored in the permission list storage unit 424 is updated to the latest permission list.

[0111] Next, the access control determination unit 422 executes a determination process for making an authorization determination for the access request based on the permission list (S45). The process of step S45 is similar to step S19 shown in FIG.

[0112] Next, an update operation of the determination information of the zone ECU will be described with reference to Fig. 7. Fig. 7 is a flowchart showing an update operation (security method) of the determination information of the zone ECU according to this embodiment. In the following, a case where the target zone ECU is zone ECU 400 will be described.

[0113] 7, the permission list update unit 425 of the secondary dynamic authentication unit 420 determines whether or not a permission list update event has occurred (S51). The permission list update event here may be, for example, the permission list being distributed as a trigger by the integrated ECU 100 or the permission list synchronization unit 426, or may be an event that has occurred after a certain period of time has elapsed since the previous permission list was distributed.

[0114] Next, if the permission list update unit 425 determines that a permission list update event has occurred (Yes in S51), it proceeds to step S52, and if it determines that a permission list update event has not occurred (No in S51), it proceeds to step S53.

[0115] Next, when the permission list update unit 425 determines that a permission list update event has occurred, it updates the permission list stored in the permission list storage unit 424 (S52). The permission list update unit 425 may transmit a request to distribute the permission list to the active authentication unit 300 via the communication units 411 and 421. Then, the permission list update unit 425 stores the permission list acquired from the active authentication unit 300 in the permission list storage unit 424. As a result, the permission list stored in the permission list update unit 425 becomes the same list as the permission list stored in the permission list storage unit 350. In addition, the permission list stored in the permission list storage unit 424 may be a part of the list stored in the permission list storage unit 350 (limited to the range used by the access control determination unit 422).

[0116] Next, the permission list update unit 425 judges whether or not to continue the process of updating the permission list (S53). If the permission list update unit 425 judges that the update process should be continued (Yes in S53), it returns to step S51 and continues the process, and if it judges that the update process should not be continued (No in S53), it ends the process.

[0117] (Other embodiments) As described above, the embodiment has been described as an example of the technology according to the present disclosure. However, the technology according to the present disclosure is not limited to this, and can be applied to an embodiment in which appropriate changes, substitutions, additions, omissions, etc. are made. For example, the following modified examples are also included in one embodiment of the present disclosure.

[0118] For example, the locations of the abnormality detection unit 81 and the monitoring unit 82 in the above embodiment are not limited to those shown in FIG.

[0119] In addition, in the above embodiment, an example has been described in which the vehicle security device is realized by the integrated ECU 100, but this is not limited to this, and the vehicle security device may also be realized by HPC (High-Performance Computing).

[0120] Furthermore, ECU801 and ECU802 (individual ECUs) in the above-described embodiment can transmit an access request to the zone ECU without going through the integrated ECU. When the zone ECU receives an access request from an individual ECU, the zone ECU may completely prohibit the access or may permit the access with limited functionality. Complete prohibition means that all access requests from the individual ECUs are determined to be authentication errors, and the access requests are not executed. Permitting the access with limited functionality means, for example, making a determination according to the contents of a permission list.

[0121] In addition, the order in which each step is performed in the flowchart is merely an example for specifically explaining the present disclosure, and an order other than the above may be used. In addition, some of the steps may be performed simultaneously (in parallel) with other steps, or some of the steps may not be performed.

[0122] In addition, the division of functional blocks in the block diagram is an example, and multiple functional blocks may be realized as one functional block, one functional block may be divided into multiple blocks, some functions may be transferred to other functional blocks, and the functions of multiple functional blocks having similar functions may be processed in parallel or in a time-sharing manner by a single piece of hardware or software.

[0123] Moreover, each of the components described in the above embodiments may be realized as software, or may be realized as an LSI, which is typically an integrated circuit. These may be individually integrated into one chip, or may be integrated into one chip to include some or all of them. Here, LSI is used, but it may be called IC, system LSI, super LSI, or ultra LSI depending on the degree of integration. Furthermore, the method of integration is not limited to LSI, and may be realized by a dedicated circuit (a general-purpose circuit that executes a dedicated program) or a general-purpose processor. After LSI manufacture, a programmable FPGA (Field Programmable Gate Array) or a reconfigurable processor that can reconfigure the connection or settings of circuit cells inside the LSI may be used. Furthermore, if an integrated circuit technology that replaces LSI appears due to the progress of semiconductor technology or a different derived technology, it is natural that the integration of the components may be performed using that technology.

[0124] A system LSI is an ultra-multifunctional LSI manufactured by integrating multiple processing units on a single chip, and specifically, is a computer system that includes a microprocessor, a ROM (Read Only Memory), a RAM (Random Access Memory), etc. Computer programs are stored in the ROM. The system LSI achieves its functions by the microprocessor operating in accordance with the computer program.

[0125] Another aspect of the present disclosure may be a computer program that causes a computer to execute each of the characteristic steps included in the security method shown in any of FIGS.

[0126] Also, for example, the program may be a program to be executed by a computer. Also, one aspect of the present disclosure may be a computer-readable non-transitory recording medium on which such a program is recorded. For example, such a program may be recorded on a recording medium and distributed or circulated. For example, the distributed program may be installed in a device having another processor, and the program may be executed by the processor, thereby making it possible to cause the device to perform each of the above processes.

[0127] In addition, the present disclosure also includes forms obtained by applying various modifications to the embodiments that a person skilled in the art may conceive, and forms realized by arbitrarily combining the components and functions of each embodiment within the scope that does not deviate from the spirit of the present disclosure.

[0128] (Additional Note) The above description of the embodiments discloses the following techniques.

[0129] (Technology 1) A vehicle security device mounted on a vehicle, the vehicle having an ECU (Electronic Control Unit) in which the vehicle security device is installed, and a zone ECU that is managed by the ECU and controls equipment mounted on the vehicle, the vehicle security device comprising: a primary dynamic authentication unit that, when there is an access request from an arbitrary access source in the vehicle to an arbitrary access destination in the vehicle, determines whether or not to cause a secondary dynamic authentication unit of the zone ECU connected to the access destination of the access request to execute an authorization decision for the access request based on information about an application of the access source and a reliability of the application of the access source which is based on at least one of information about the application of the access source and a state of the vehicle; and a connection management unit that outputs the access request to the zone ECU of the access destination when it is determined that the authorization decision should be executed in the secondary dynamic authentication unit corresponding to the access destination.

[0130] This makes it possible to apply a zero trust architecture (ZTA) to an in-vehicle system (e.g., a central-zone architecture), and distribute the load of authorization judgment to the primary dynamic authentication unit and the secondary dynamic authentication unit while maintaining a secure (safe) state. Therefore, it is possible to realize a vehicle security device that can introduce a zero trust architecture while suppressing processing concentration and security degradation.

[0131] Although it is possible to have only the zone ECU make the authorization decision, this does not conform to the idea of ​​zero trust architecture (ZTA) and there is a risk of security being compromised. According to the above, which ECU should make the authorization decision is determined based on the reliability of the application, so that it is possible to prevent security from being compromised.

[0132] (Technology 2) The vehicle has a plurality of zone ECUs, the plurality of zone ECUs including a zone ECU having the secondary dynamic authentication unit and a zone ECU not having the secondary dynamic authentication unit, and the primary dynamic authentication unit further makes the determination based on authentication feasibility information indicating whether or not each of the plurality of zone ECUs has the secondary dynamic authentication unit.

[0133] According to this, since the authentication permission information is used, it is possible to prevent a determination that a zone ECU that does not have a secondary dynamic authentication unit should execute an authorization determination (i.e., to allow a requested resource to be accessed without an authorization determination), and thus it is possible to more reliably prevent a deterioration in security.

[0134] (Technology 3) A vehicle security device described in Technology 2, in which the primary dynamic authentication unit determines whether the zone ECU of the destination of access has the secondary dynamic authentication unit based on the authentication feasibility information, and performs the determination if the zone ECU of the destination of access has the secondary dynamic authentication unit.

[0135] This makes it possible to distribute the load of authorization decisions among zone ECUs having secondary dynamic authentication units.

[0136] (Technical 4) In the vehicle security device according to any one of Technical 1 to 3, the active authentication unit further makes the determination based on a security state of the vehicle.

[0137] According to this, the security status of the vehicle is also taken into consideration, so that the load of the authorization decision can be distributed at an appropriate timing, for example, when the security status is good.

[0138] (Technology 5) A vehicle security device described in any of Technologies 1 to 4, wherein the vehicle security device has one or more virtual machines, and the trust level is set to a different value depending on whether the virtual machine on which the application of the access source is installed is in-house developed or externally procured.

[0139] According to this, the location where the application is located can be reflected in the reliability, making it possible to obtain a more accurate reliability.

[0140] (Technology 6) The vehicle security device according to Technology 5, wherein the degree of trust is higher when the virtual machine is in-house developed than when the virtual machine is externally procured.

[0141] This allows the reliability of an application installed in a virtual machine that poses a smaller security risk to be set high.

[0142] (Technology 7) In the vehicle security device according to any one of Techniques 1 to 6, the trustworthiness is set based on a certificate obtained from the application of the access source, the certificate including an authority level of the application.

[0143] According to this, the certificate given to the application can be reflected in the reliability, and a more accurate reliability can be obtained.

[0144] (Technology 8) In the vehicle security device according to any one of Techniques 1 to 7, the reliability is set depending on whether an abnormality has been detected in the application of the access source.

[0145] According to this, the abnormal state of the application can be reflected in the reliability, and a more accurate reliability can be obtained.

[0146] (Technology 9) A vehicle security device described in any of Technologies 1 to 8, wherein when the primary dynamic authentication unit determines that the authorization decision should be executed in the secondary dynamic authentication unit corresponding to the access destination, the primary dynamic authentication unit does not execute the authorization decision for the access request, and when the primary dynamic authentication unit determines that the authorization decision should not be executed in the secondary dynamic authentication unit corresponding to the access destination, the primary dynamic authentication unit executes the authorization decision for the access request.

[0147] According to this, since only one of the primary dynamic authentication unit and the secondary dynamic authentication unit performs the authorization decision, the burden of the authorization decision can be more reliably distributed.

[0148] (Technology 10) A vehicle security device described in any one of Technologies 1 to 9, wherein the primary dynamic authentication unit determines to execute the authorization decision in each of the primary dynamic authentication unit and the secondary dynamic authentication unit corresponding to the access destination when a predetermined condition is satisfied.

[0149] According to this, when a predetermined condition is satisfied, the authorization decision is made by each of the primary dynamic authentication unit and the secondary dynamic authentication unit, thereby improving security.

[0150] (Technology 11) The vehicle security device described in Technology 1, wherein the specified condition includes at least one of the following: the access request is the first access after the reliability is updated; it is the timing to execute the authorization decision in each of the primary dynamic authentication unit and the secondary dynamic authentication unit; and an instruction has been obtained from outside the vehicle.

[0151] According to this, authorization decisions can be made in each of the primary dynamic authentication unit and the secondary dynamic authentication unit at the time of the first access after the reliability has been updated, at the timing when an authorization decision is made in each of the primary dynamic authentication unit and the secondary dynamic authentication unit, and when instructions are obtained from outside the vehicle.

[0152] (Technology 12) The vehicle security device according to any one of Technologies 1 to 11, wherein the device includes at least one of a terminal accelerator, a sensor, a motor, a battery, and a charger.

[0153] This makes it possible to distribute the processing load for access requests whose access destination is at least one of a terminal accelerator, a sensor, a motor, a battery, and a charger.

[0154] (Technology 13) A security method executed by a vehicle security device mounted on a vehicle, the vehicle having an ECU (Electronic Control Unit) in which the vehicle security device is installed, and a zone ECU that is managed by the ECU and controls equipment mounted on the vehicle, the security method, when there is an access request from an arbitrary access source in the vehicle to an arbitrary access destination in the vehicle, determines whether or not to cause a secondary dynamic authentication unit of the zone ECU connected to the access destination of the access request to execute an authorization decision for the access request based on a reliability of the application of the access source which is based on at least one of a state of the application of the access source and a state of the vehicle, and when it is determined that the authorization decision is to be executed in the secondary dynamic authentication unit corresponding to the access destination, outputs the access request to the zone ECU of the access destination.

[0155] This provides the same effects as the above-mentioned vehicle security device.

[0156] (Technology 14) A program for causing a computer to execute the above security method.

[0157] This provides the same effects as the above-mentioned vehicle security device.

[0158] These general or specific aspects may be realized by a system, a method, an integrated circuit, a computer program, or a non-transitory recording medium such as a computer-readable CD-ROM, or may be realized by any combination of the system, the method, the integrated circuit, the computer program, or the recording medium. The program may be stored in the recording medium in advance, or may be supplied to the recording medium via a wide area communication network including the Internet. [Industrial Applicability]

[0159] The present disclosure can be applied to in-vehicle networks and the like. [Explanation of symbols]

[0160] 1. Vehicle Security System 10. Hardware 20. Security Software 30 Hypervisor 40, 50, 60 Virtual Machines 41 OS 42, 81 Abnormality detection section 43, 82 Monitoring Department 51 Sandbox 52 3rd App 53 IVI App 70 Trust Zone 90 Resources 91 HSM 92 Storage 100 Integrated ECU (Vehicle Security Device) 200, 410, 510, 610, 710 Connection Management Unit 210, 310, 411, 421 Communications Department 220, 412 Access control execution unit 230, 413 Access request receiving unit 240 Through Processing Execution Unit 300 Active authentication section 320, 422 Access control decision unit 330, 423 Vehicle Status Collection Department 340 Through processing judgment unit 350, 424 Permission list storage section 360, 425 Permission List Update Department 370, 426 Allow list synchronization part 380 Reliability Information Generation Unit 391 Reliability information storage unit 392 Dynamic authentication distributed placement information storage unit 400, 500, 600, 700 Zone ECU 401 Normal area 402 Trust Region 420, 520, 620, 720 Secondary dynamic authentication unit 801 ECU 802 ECU 901 Actuator 902 Sensor

Claims

1. A vehicle security device mounted on a vehicle, The vehicle includes an ECU (Electronic Control Unit) in which the vehicle security device is installed, and a zone ECU that is controlled by the ECU and controls devices mounted on the vehicle, The vehicle security device includes: a primary dynamic authentication unit that, when an access request is made from an arbitrary access source in the vehicle to an arbitrary access destination in the vehicle, determines whether or not to cause a secondary dynamic authentication unit of the zone ECU connected to the access destination of the access request to execute an authorization decision for the access request based on information about an application of the access source and a reliability of the application of the access source based on at least one of a state of the vehicle; a connection management unit that outputs the access request to the zone ECU of the access destination when it is determined that the authorization determination is to be performed in the secondary dynamic authentication unit corresponding to the access destination. Vehicle security device.

2. The vehicle includes a plurality of the zone ECUs, The plurality of zone ECUs include a zone ECU having the secondary dynamic authentication unit and a zone ECU not having the secondary dynamic authentication unit, The primary dynamic authentication unit further performs the determination based on authentication availability information indicating whether or not each of the plurality of zone ECUs has the secondary dynamic authentication unit.

10. The vehicle security device of claim 1.

3. The primary dynamic authentication unit determines whether the zone ECU of the access destination has the secondary dynamic authentication unit based on the authentication availability information, and performs the determination if the zone ECU of the access destination has the secondary dynamic authentication unit.

3. The vehicle security device of claim 2.

4. The active authentication unit further performs the determination based on a security state of the vehicle. A vehicle security device according to any one of claims 1 to 3.

5. The vehicle security device includes one or more virtual machines; The reliability is set to a different value depending on whether the virtual machine on which the application of the access source is installed is an in-house developed one or an externally procured one. A vehicle security device according to any one of claims 1 to 3.

6. When the virtual machine is in-house developed, the reliability is higher than when the virtual machine is externally procured.

6. A vehicle security device according to claim 5.

7. The trust level is set based on a certificate obtained from the application of the access source, the certificate including the authority level of the application. A vehicle security device according to any one of claims 1 to 3.

8. The reliability is set depending on whether an abnormality has been detected in the application of the access source. A vehicle security device according to any one of claims 1 to 3.

9. When the primary dynamic authentication unit determines that the secondary dynamic authentication unit corresponding to the access destination should execute the authorization decision, the primary dynamic authentication unit does not execute the authorization decision for the access request, and when the primary dynamic authentication unit determines that the secondary dynamic authentication unit corresponding to the access destination should not execute the authorization decision, the primary dynamic authentication unit executes the authorization decision for the access request. A vehicle security device according to any one of claims 1 to 3.

10. When a predetermined condition is satisfied, the primary authentication unit determines that the authorization decision is to be performed in each of the primary authentication unit and the secondary dynamic authentication unit corresponding to the access destination. A vehicle security device according to any one of claims 1 to 3.

11. The predetermined condition includes at least one of the following: the access request is the first access after the reliability is updated; it is time for the primary dynamic authentication unit and the secondary dynamic authentication unit to execute the authorization decision; and an instruction has been obtained from outside the vehicle.

11. A vehicle security device according to claim 10.

12. The device includes at least one of a terminal accelerator, a sensor, a motor, a battery, and a charger. A vehicle security device according to any one of claims 1 to 3.

13. A security method executed by a vehicle security device mounted in a vehicle, comprising: The vehicle includes an ECU (Electronic Control Unit) in which the vehicle security device is installed, and a zone ECU that is controlled by the ECU and controls devices mounted on the vehicle, The security method includes: when an access request is made from an arbitrary access source in the vehicle to an arbitrary access destination in the vehicle, a secondary dynamic authentication unit of the zone ECU connected to the access destination of the access request determines whether or not to execute an authorization decision for the access request based on a reliability of the application of the access source which is based on at least one of a state of the application of the access source and a state of the vehicle; When it is determined that the authorization decision is to be performed in the secondary dynamic authentication unit corresponding to the access destination, the access request is output to the zone ECU of the access destination. Security methods.

14. A program for causing a computer to execute the security method according to claim 13.

Images