Information processing method, information processing device, and program

Abstract

This information processing method is executed by an information processing device in a control network system, wherein the control network system includes: a plurality of electronic control devices that are each capable of executing a service including execution of a prescribed process and are capable of accessing each other for services; and a plurality of edge access permission devices that each determine whether or not to permit access on the basis of a prescribed access policy. The information processing method comprises: acquiring, from each of the plurality of edge access permission devices, a policy verification result including the result of determining whether or not to permit access (S800); and outputting, on the basis of the policy verification result from each of the plurality of edge access permission devices, verification information relating to a master policy verification result including the final determination result on whether or not to permit access (S801).

Description

Information processing method, information processing device, and program

[0001] The present disclosure relates to an information processing method, an information processing device, and a program.

[0002] Conventionally, there is a concept called zero trust architecture to reduce security risks (see, for example, Non-Patent Document 1). In conventional zero trust architecture, it is considered to determine whether to allow access to a resource from an access source based on information about the access source.

[0003] Scott Rose, Oliver Borchert, Stu Mitchell, Sean Connelly, “Zero Trust Architecture”, NIST Special Publication 800-207, August 2020, (https: / / doi.org / 10.6028 / NIST.SP.800-207)

[0004] It is conceivable to apply the zero trust architecture to in-vehicle network systems as well to enhance safety. Examples of resources in in-vehicle network systems include users' personal information and functions provided by electronic control units (ECUs) that constitute the in-vehicle network system, such as services.

[0005] However, in control network systems such as in-vehicle network systems, there are services that require real-time and / or reliable communication, and the inability to use the services may affect the safety of the object (e.g., a moving object) in which the system is installed.

[0006] The present disclosure provides an information processing method and the like for realizing a secure control network system while maintaining the safety of an object on which the control network system is installed.

[0007] An information processing method according to one aspect of the present disclosure is an information processing method executed by an information processing device in a control network system, wherein the control network system includes a plurality of electronic control devices, each capable of executing services including the execution of predetermined processing and capable of accessing each other for the services, and a plurality of edge access permission devices, each capable of determining whether the access is possible based on a predetermined access policy, and the information processing method obtains a policy verification result from each of the plurality of edge access permission devices, the policy verification result including the determination result of whether the access is possible, and outputs verification information regarding a master policy verification result including a final determination result of whether the access is possible based on the policy verification result from each of the plurality of edge access permission devices.

[0008] An information processing device according to one aspect of the present disclosure is an information processing device in a control network system, wherein the control network system includes a plurality of electronic control devices, each capable of executing services including the execution of predetermined processing and capable of accessing each other for services, and a plurality of edge access permission devices, each determining whether or not the access is possible based on a predetermined access policy, and the information processing device includes an acquisition unit that acquires a policy verification result including the determination result of whether or not the access is possible from each of the plurality of edge access permission devices, and an output unit that outputs verification information regarding a master policy verification result including a final determination result of whether or not the access is possible based on the policy verification result from each of the plurality of edge access permission devices.

[0009] A program according to one aspect of the present disclosure is a program for causing a computer to execute an information processing method according to one aspect of the present disclosure.

[0010] According to an information processing method and the like according to one aspect of the present disclosure, it is possible to realize a secure control network system while maintaining the safety of the object on which the control network system is installed.

[0011] FIG. 1 is a diagram illustrating a configuration of an in-vehicle network system according to an embodiment. FIG. 2 is a block diagram illustrating a configuration of a central ECU according to an embodiment. FIG. 3 is a block diagram illustrating a functional configuration of a zone ECU according to an embodiment. FIG. 4 is a block diagram illustrating a functional configuration of a camera ECU according to an embodiment. FIG. 5 is a diagram illustrating an example of an access policy according to an embodiment. FIG. 6 is a diagram illustrating an example of a vehicle state according to an embodiment. FIG. 7 is a diagram illustrating an example of user information according to an embodiment. FIG. 8 is a sequence diagram illustrating a processing procedure for access permission according to an embodiment. FIG. 9 is a sequence diagram illustrating a processing procedure for access permission according to an embodiment. FIG. 10 is a flowchart illustrating a processing procedure for a master policy determination unit and a policy enforcement unit of a central ECU according to an embodiment. FIG. 11 is a flowchart illustrating a processing procedure for a policy determination unit and a policy enforcement unit of a zone ECU according to an embodiment. FIG. 12 is a flowchart illustrating a processing procedure for changing an important characteristic of a service depending on a vehicle state in a master policy determination unit of a central ECU according to an embodiment. FIG. 13 is a flowchart illustrating a processing procedure when an ECU whose policy verification result received by the central ECU according to an embodiment is different from the others is present. FIG. 14 is a diagram illustrating a configuration of an in-vehicle network system according to a first modified embodiment. FIG. 15 is a block diagram illustrating a functional configuration of a central ECU according to the first modified embodiment. Fig. 16 is a block diagram showing the functional configuration of a zone ECU according to a first modification of the embodiment. Fig. 17 is a diagram showing an example of a vehicle state according to the first modification of the embodiment. Fig. 18 is a flowchart showing a processing procedure for determining a threshold value in a master policy determination unit of a central ECU according to the first modification of the embodiment. Fig. 19 is a flowchart showing a processing procedure when an ECU with a policy verification result different from others received by the central ECU according to a second modification of the embodiment is present. Fig. 20 is a diagram showing an example of a visualized state when a zone ECU with a policy verification result different from others is present according to the second modification of the embodiment.

[0012] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings.

[0013] Note that the embodiments described below are intended to illustrate specific examples of the present disclosure. The numerical values, shapes, components, steps, step orders, and the like shown in the following embodiments are merely examples and are not intended to limit the present disclosure. Furthermore, among the components in the following embodiments, components that are not recited in independent claims are described as optional components. Furthermore, in all embodiments, the respective contents can be combined. Furthermore, various modifications made to each embodiment of the present disclosure within the scope conceivable by a person skilled in the art are also included in the present disclosure, as long as they do not deviate from the spirit of the present disclosure.

[0014] Furthermore, in this specification, terms indicating relationships between elements such as "same," as well as numerical values ​​and numerical ranges, are not expressions that express only the strict meaning, but are expressions that also include a substantially equivalent range, for example, a difference of about several percent (or about 10%).

[0015] (Embodiment) [Configuration] First, the configuration of an in-vehicle network system according to an embodiment will be described.

[0016] FIG. 1 is a diagram showing the overall configuration of an in-vehicle network system according to this embodiment.

[0017] The in-vehicle network system includes a central ECU 100, zone ECUs 200a, 200b, 200c, and 200d (hereinafter also referred to as zone ECU 200a, etc.), a camera ECU 300a, a charger ECU 300b, a brake ECU 300c, and a motor ECU 300d.

[0018] The in-vehicle network system is a system in which electronic control units in the vehicle 10 communicate with each other. For example, the camera ECU 300a and the zone ECU 200a communicate with each other via the in-vehicle network. The zone ECU 200a also communicates with the central ECU 100 or the zone ECU 200b via the in-vehicle network. The in-vehicle network system is an example of a control network system.

[0019] The in-vehicle network is configured based on in-vehicle network communication standards called Controller Area Network (CAN), LIN, FlexRay, and Ethernet (registered trademark).

[0020] The vehicle 10 is used by a user. The vehicle 10 is, for example, an automobile, but may also be a motorcycle or other mobility system such as a ship or an airplane. The vehicle 10 may also be an autonomous vehicle or a manually driven vehicle. The vehicle 10 is an example of an object in which a control network system is installed.

[0021] The central ECU 100 is an electronic control unit that performs the central function of vehicle control. The central ECU 100 has a connectivity function and wirelessly communicates with a server outside the vehicle 10 via a mobile phone network or Wi-Fi (registered trademark), etc., to notify the vehicle status and download firmware. The central ECU 100 is also equipped with an autonomous driving application that acquires and controls information from each ECU to realize the autonomous driving function. The central ECU 100 is an example of an information processing device or an access-permitting device.

[0022] The zone ECUs 200a to 200d are arranged at various locations in the in-vehicle network, function as gateways of the sub-network, and communicate with the central ECU 100 or other zone ECUs. The zone ECUs 200a to 200d are an example of edge access permission devices.

[0023] The camera ECU 300a acquires camera information and transmits it to the in-vehicle network.

[0024] The charger ECU 300b controls charging of the battery mounted on the vehicle 10. The charger ECU 300b and the zone ECU 200a communicate with each other via an in-vehicle network.

[0025] The brake ECU 300c controls the brakes of the vehicle 10. The brake ECU 300c and the zone ECU 200c communicate with each other via an in-vehicle network.

[0026] The motor ECU 300d controls the motor of the vehicle. The motor ECU 300d and the zone ECU 200d communicate with each other via an in-vehicle network.

[0027] When communicating with other ECUs, each ECU exchanges various data, control instructions, etc., using, for example, Scalable Service Oriented Middleware over IP (SOME / IP protocol). In this embodiment, an example is shown in which one ECU is connected to each of the zone ECUs 200a to 200d, but the number of connected ECUs is not particularly limited to this.

[0028] As described above, the in-vehicle network system of this embodiment includes a plurality of ECUs (e.g., camera ECU 300a, charger ECU 300b, brake ECU 300c, motor ECU 300d) each capable of executing services including the execution of predetermined processing and capable of accessing each other for services, and a plurality of zone ECUs 200a, etc. each determining whether or not to allow access based on a predetermined access policy.

[0029] FIG. 2 is a block diagram showing the functional configuration of the central ECU 100 according to this embodiment.

[0030] The central ECU 100 includes a center communication unit 101, a vehicle control application unit 102, a driver application unit 103, an autonomous driving application unit 104, an in-vehicle network communication unit 105, a master policy determination unit 106, a policy enforcement unit 107, an access policy storage unit 108, a vehicle state storage unit 109, and a user information storage unit 110. Furthermore, the central ECU 100 may be an ECU (integrated ECU) that integrates functions that were previously separated into multiple ECUs to address the issues of increased development time and cost associated with the increasing complexity of in-vehicle network systems. The integrated ECU is an ECU that uses virtualization technology to run multiple virtual computers (virtual machines: VMs) on a single ECU. For example, the vehicle control application unit 102, the driver application unit 103, and the autonomous driving application unit 104 may be implemented by virtual machines. The vehicle control application unit 102, the driver application unit 103, and the autonomous driving application unit 104 are logically separated by virtualization technology. Different IP addresses are assigned to the vehicle control application unit 102, the driver application unit 103, and the autonomous driving application unit 104.

[0031] The center communication unit 101 is a communication interface that communicates with a server external to the vehicle 10. The center communication unit 101 functions as an acquisition unit that acquires a policy verification result including a determination result on whether access is permitted. The center communication unit 101 may also function as an output unit that outputs verification information related to the master policy verification result to an external server.

[0032] The vehicle control application unit 102 is an application that processes or controls data acquired from each ECU in order to realize basic functions of the vehicle 10 such as running, turning, and stopping.

[0033] The driver application unit 103 is an application for improving the user experience of the vehicle 10, and controls the air conditioning in the vehicle or the infotainment system.

[0034] The autonomous driving application unit 104 is an application for executing autonomous driving, and acquires sensing information outside the vehicle from ECUs other than the central ECU 100 and controls the vehicle 10.

[0035] The in-vehicle network communication unit 105 is a communication interface for the in-vehicle network and exchanges messages with the zone ECUs 200a to 200d. The in-vehicle network communication unit 105 also has the function of a network switch that controls the transfer of communications. The in-vehicle network communication unit 105 may also function as an output unit that outputs verification information related to the master policy verification result to each zone ECU 200a, etc.

[0036] When there is a request to access a vehicle function, the master policy determination unit 106 determines whether to permit access to the function. Specifically, based on the access policy stored in the access policy holding unit 108, the master policy determination unit 106 determines whether the destination and source of the message content acquired by the in-vehicle network communication unit 105 match. If the destination and source of the acquired message content match, the in-vehicle network communication unit 105 notifies the policy enforcement unit 107 that access is permitted. If the destination and source of the acquired message content do not match, the in-vehicle network communication unit 105 notifies the policy enforcement unit 107 that access is denied. Note that the master policy determination unit 106 may also determine whether the service ID and the destination IP address match.

[0037] Furthermore, master policy determination unit 106 may comprehensively determine access permission based not only on the access policies stored in access policy holding unit 108 but also on the policy verification results of the access policies notified by policy determination units 202 disposed in zone ECUs 200a to 200d. Thereafter, master policy determination unit 106 notifies policy enforcement units 203 of zone ECUs 200a to 200d of whether access permission is granted or denied.

[0038] The policy enforcement unit 107 permits or denies access to vehicle functions based on the notification of access permission or denial notified from the master policy determination unit 106. Specifically, the policy enforcement unit 107 controls the transfer or discard of messages acquired by the in-vehicle network communication unit 105.

[0039] The access policy holding unit 108 is a storage that stores information about policies for controlling access to vehicle functions. Details will be described later with reference to Fig. 5. The access policy holding unit 108 is realized by, for example, but not limited to, a semiconductor memory or a hard disk drive (HDD).

[0040] The vehicle state storage unit 109 is a storage that stores information on the current vehicle state. Details will be described later with reference to Fig. 6. The vehicle state storage unit 109 is realized by, for example, a semiconductor memory or a HDD, but is not limited to these.

[0041] The user information storage unit 110 is a storage that stores user information. Details will be described later with reference to Fig. 7. The user information storage unit 110 is realized by, for example, a semiconductor memory or a HDD, but is not limited to these.

[0042] 3 is a block diagram showing the functional configuration of the zone ECU 200a according to this embodiment. Note that the zone ECUs 200b, 200c, and 200d have the same configuration, so a description of these will be omitted.

[0043] The zone ECU 200 a includes an in-vehicle network communication unit 201 , a policy determination unit 202 , a policy enforcement unit 203 , an access policy storage unit 204 , and a vehicle state storage unit 205 .

[0044] The in-vehicle network communication unit 201 is a communication interface for the in-vehicle network, and communicates with at least one of the central ECU 100 and the camera ECU 300a in the zone. The in-vehicle network communication unit 201 also has a network switch function that controls communication transfer as necessary.

[0045] Based on the access policy stored in the access policy holding unit 204, the policy determination unit 202 determines whether the destination and source of the message content acquired by the in-vehicle network communication unit 201 match. If the destination and source of the message content match, the policy determination unit 202 notifies the policy enforcement unit 203 that access is permitted. If the destination and source of the message content do not match, the policy determination unit 202 notifies the policy enforcement unit 203 that access is denied. Note that the policy determination unit 202 may also determine whether the service ID and the destination IP address match. The determination result of the policy determination unit 202 is an example of a policy verification result, and includes a determination result as to whether access is permitted or not.

[0046] Also, depending on the content of the message, instead of notifying the policy enforcement unit 203 of the verification result of the access permission, the policy judgment unit 202 may notify the master policy judgment unit 106 of the central ECU 100, and the master policy judgment unit 106 may notify the policy enforcement unit 203 of the final decision result of whether access permission is allowed or denied.

[0047] Policy enforcement unit 203 has the same function as policy enforcement unit 107, and permits or denies access to vehicle functions based on an access permission / denial notification sent from policy determination unit 202 or master policy determination unit 106. Specifically, policy enforcement unit 203 controls the transfer or discarding of messages acquired by in-vehicle network communication unit 201. For example, policy enforcement unit 203 transfers messages for which access is permitted and discards messages for which access is denied.

[0048] The access policy holding unit 204 is a storage that stores information related to policies for controlling access to vehicle functions. Basically, the access policy holding unit 204 holds the same information as the access policy holding unit 108 of the central ECU 100, and details will be described later with reference to FIG. 5. The access policy holding unit 204 is realized by, for example, a semiconductor memory or a HDD, but is not limited to these.

[0049] The vehicle state storage unit 205 is a storage that stores information about the current vehicle state. Basically, the vehicle state storage unit 205 stores the same information as the vehicle state storage unit 109 included in the central ECU 100, and details will be described later using Fig. 6. The vehicle state storage unit 205 is realized by, for example, a semiconductor memory or a HDD, but is not limited to these.

[0050] 4 is a block diagram showing the functional configuration of the camera ECU 300a according to this embodiment. Note that the charger ECU 300b, brake ECU 300c, and motor ECU 300d have substantially the same configurations, so descriptions thereof will be omitted.

[0051] The camera ECU 300 a includes an application unit 301 and a communication unit 302 .

[0052] The application unit 301 is equipped with applications that realize the functions of the ECUs. The camera ECU 300a has activated a service that acquires camera information and provides the camera information to necessary ECUs. The charger ECU 300b has activated a service that provides the battery charge state or a service that controls battery charging. The brake ECU 300c has activated a service that notifies the brake state or a service that controls the brake. The motor ECU 300d has activated a service that notifies the motor state or a service that controls the motor.

[0053] The communication unit 302 is a communication interface for an in-vehicle network, and communicates with the zone ECU 200a.

[0054] [Specific Examples of Various Information] Next, various information used in the in-vehicle network system according to the embodiment will be described.

[0055] 5 is a diagram showing an example of an access policy according to this embodiment. The access policy is information stored in the access policy storage units 108 and 204. For example, the access policies stored in the access policy storage units 108 and 204 are the same information (synchronized information).

[0056] The access policy is information indicating the destination IP address and the source IP address for each function (service ID), and also defines important characteristics for each function. The access policy also stores version information of the access policy. At least the service ID and the destination IP address are information included in the message (a search message, which is a request for access to a vehicle function and will be described later).

[0057] In FIG. 5 , the access policy version is 1.0, the functions of vehicle 10 include camera information (service ID: 0x10), brake control (service ID: 0x20), charger control (service ID: 0x30), and user information acquisition (service ID: 0x40), the IP addresses permitted as service destinations for each function are 192.168.0.20, 192.168.0.10, 192.168.0.10, and 192.168.0.30, the IP addresses permitted as service sources are 192.168.0.10, 192.168.0.5, 192.168.0.30, and 192.168.0.10, respectively, and the important characteristics are availability, security, availability, and confidentiality, respectively.

[0058] The communication of the in-vehicle network may be realized by, for example, SOME / IP, and the service ID corresponds to the Message ID or Service ID in SOME / IP. Note that the in-vehicle protocol of the in-vehicle network is not limited to SOME / IP.

[0059] The important characteristics are classified into availability, security, and confidentiality. Note that the important characteristics may include at least two of availability, security, and confidentiality.

[0060] Availability is assigned to services for which service continuity is an important factor, such as services where vehicle control is affected by the interruption of information, such as camera information and status notification of the vehicle 10. For example, an example of a service (first service) that requires availability is the exchange of sensor data acquired by a sensor such as a camera, but is not limited to this.

[0061] For services where availability is important, real-time performance or service continuity is required, so the master policy determination unit 106 or policy determination unit 202 makes a decision to block communication for that service more carefully than safety and confidentiality. In other words, rather than a single policy determination unit 202 making a decision to deny access, the master policy determination unit 106 makes a decision to deny access based on the results of multiple policy determination units 202. Also, because real-time performance is required, the master policy determination unit 106 performs access control to permit communication until it makes a decision to deny access.

[0062] Safety is assigned to services that may have a direct impact on vehicle control. For example, a service that receives a brake or motor control command and controls the brake or motor falls under this category. For example, a service that requires safety (third service) may be, but is not limited to, a service related to actuator control that requires real-time performance.

[0063] For safety-critical services, it is necessary to immediately block access to unauthorized services, and real-time performance is also required because the services involve control of the vehicle 10. Therefore, whether to permit or deny access to the service is determined based on the decision of a single policy determination unit 202. For example, each zone ECU 200a etc. determines whether to permit or deny access to the service in its own device based on the policy verification result of its own policy determination unit 202.

[0064] Confidentiality is assigned to services that do not want information contained in the service to be read by any application other than authorized applications. For example, a service that provides information related to a user's personal information falls into this category. For example, a service (second service) that requires confidentiality includes, but is not limited to, the exchange of data related to personal information or confidential information.

[0065] For services where confidentiality is important, real-time performance is not required, but careful access permission decisions are required. Therefore, the master policy decision unit 106 or the policy decision unit 202 decides whether to permit access for the communication of the service based on the results of multiple policy decision units 202. Furthermore, each zone ECU performs access control so as to suspend communication until the master policy decision unit 106 decides whether to permit access.

[0066] The functions are not limited to the example shown in FIG. 5, and other functions may be available.

[0067] In addition, it is not necessary to set values ​​for both the destination IP address and the source IP address; only one of the IP addresses may be set. Also, multiple IP addresses may be set. For example, the access policy may include information on either or both of the ECUs that are permitted to access the service among the multiple ECUs and the ECUs that are permitted to provide the service among the multiple ECUs.

[0068] Furthermore, the information indicating the destination and source does not have to be IP addresses, but may be, for example, a MAC address or an identifier for identifying an ECU or an application.

[0069] The service ID may be any identifier of a service, may be included in a message, or may be a port number.

[0070] Furthermore, there may be services for which no important characteristics are set, and for services for which no important characteristics are set, access permission / denial may be determined according to a standard set by default (for example, a determination by a single policy determination unit 202).

[0071] The access policy may be encrypted and stored in the access policy storage units 108 and 204 .

[0072] Furthermore, access control may be set in the access policy so that it cannot be referenced by anyone other than the master policy determining unit 106 and the policy determining unit 202 .

[0073] The access policy may also be updated according to a regular procedure, such as after verifying that the version of the access policy received from an external server has not been rolled back and that the digital signature of the access policy is correct.

[0074] 6 is a diagram showing an example of the vehicle state according to this embodiment. The vehicle state is information stored in the vehicle state storage units 109 and 205.

[0075] The vehicle state stores the current vehicle state based on information notified via the in-vehicle network. Specifically, the vehicle state storage units 109 and 205 store the vehicle state, such as the driving state of the vehicle 10, whether the autonomous driving mode is ON or OFF, and the remaining battery power. Figure 6 shows an example of a state in which the driving state is driving, the autonomous driving mode is OFF, and the remaining battery power is 70%.

[0076] The master policy determination unit 106 and the policy determination unit 202 can change the important characteristics of each service in the access policy depending on the vehicle state. For example, when the vehicle 10 is stopped, the master policy determination unit 106 and the policy determination unit 202 use the vehicle state to deal with cases where the important characteristics of a service change depending on the current vehicle state, such as changing the important characteristic of the charging control service to safety.

[0077] The vehicle state is not limited to the example shown in Fig. 6 and may include, for example, a diagnostic mode state or an update state. The diagnostic mode state indicates, for example, the mode (e.g., ON / OFF) of the self-diagnosis function of each ECU. The update state indicates the update state (e.g., version) of each application and access policy installed in the vehicle 10.

[0078] 7 is a diagram showing an example of user information according to this embodiment. The user information is information stored in the user information storage unit 110.

[0079] The user information storage unit 110 stores the name, address, telephone number, and credit card information of the vehicle user as user information. The name of the vehicle user may be, for example, the name of the user currently using the vehicle 10.

[0080] In the example shown in FIG. 7, the user's name is Yamada Taro, his address is XXXX in Osaka Prefecture, his telephone number is 090XXXXXXXXX, and his credit card information is YYYYYY.

[0081] The user information stored in the user information storage unit 110 is not limited to the information shown in Fig. 7. For example, the user information storage unit 110 may store address book information, favorite location information, and the like acquired from an information terminal such as a smartphone of the user, as the user information.

[0082] Furthermore, the user information may be encrypted and stored in the user information storage unit 110 .

[0083] [Processing Procedure] Next, a processing procedure of the in-vehicle network system according to this embodiment will be described.

[0084] 8 is a sequence diagram (information processing method, access permission method) showing the procedure for access permission according to this embodiment. Specifically, FIG. 8 is a sequence diagram showing the procedure when the autonomous driving application of the central ECU 100 accesses the camera information service of the camera ECU 300a.

[0085] First, the central ECU 100 transmits a camera information service search message for requesting use of the camera information service, for example, when the autonomous driving function is turned on (S100). As the camera information service search message, a SOME / IP-SD (Service Discovery) message (Find message) is broadcast from the central ECU 100 to the zone ECUs 200a, 200b, 200c, and 200d.

[0086] When each of the zone ECUs 200a, 200b, 200c, and 200d receives a search message for the camera information service, it checks whether the message conforms to an access policy (S101). That is, when each of the zone ECUs 200a, 200b, 200c, and 200d receives a search message for the camera information service, it determines the access policy of the search message.

[0087] The search message for the camera information service includes a camera information ID (0x10 in the example of FIG. 5) as a service ID and a destination IP address (the IP address of the central ECU 100 or the application unit that sent the search message). In step S101, the policy determination unit 202 of each zone ECU checks whether the ID of the camera information and the destination IP address included in the search message match the access policy shown in FIG. 5. For example, the policy determination unit 202 of each zone ECU determines whether the pair of the camera information ID and the destination IP address included in the search message is included in the access policy shown in FIG. 5.

[0088] Thereafter, since the important characteristic of the camera information service is availability, the zone ECUs 200a, 200b, 200c, and 200d first forward a search message for the camera information service to their respective zones (S102). For example, if each zone ECU 200a does not know whether a camera ECU capable of providing the camera information service is connected to its own zone and the important characteristic is availability, it forwards the search message regardless of the result of step S101. Note that if each zone ECU 200a has knowledge of (stores) information about services that the ECU in its own zone can provide, the processing of step S102 may be omitted.

[0089] Furthermore, the zone ECUs 200a, 200b, 200c, and 200d respond (transmit) to the central ECU 100 that the verification result of the access policy (policy verification result) is OK (S103). In step S103, the result of the processing in step S101 (verification result) is transmitted to the central ECU 100, which is the ECU to which the access policy is to be provided. Step S103 is executed independently of the processing in step S102.

[0090] Since the policy verification results from the zone ECUs 200a, 200b, 200c, and 200d are all OK, the central ECU 100 permits access to the camera information service and notifies the zone ECUs 200a, 200b, 200c, and 200d of the permission (S104).

[0091] In step S104, the master policy determination unit 106 of the central ECU 100 outputs a master policy verification result (here, access permission), which is the final judgment result on whether access is permitted for the camera information service search message sent in step S100, based on the policy verification results sent from the zone ECUs 200a, 200c, and 200d.

[0092] The zone ECU 200a transfers the response (SOME / IP-SD message (Offer message)) received from the camera ECU 300a of its own zone to the central ECU 100 (S105). That is, the zone ECU 200a transfers the response from the camera ECU 300a to the central ECU 100. This response indicates that the camera information is available in response to the transfer of the search message in step S102. This allows the central ECU 100 to obtain which zone ECU the camera ECU 300a is connected to.

[0093] Based on the Offer message received from the camera ECU 300a, the central ECU 100 transmits a message (a usage request) requesting the use of the camera information service to the zone ECU 200a (S106). After that, a session is established between the central ECU 100 and the camera ECU 300a, and the central ECU 100 can use the camera information service. The usage request is an example of verification information related to the master policy verification result.

[0094] Note that there is no particular limitation on the timing of the response of the access policy verification result in step S103. Furthermore, depending on the timing of the response of the access policy verification result in step S103, the determination of access permission to the camera information service in step S104 may be made later than in step S105. However, because availability is an important characteristic of the camera information service, the response from the camera ECU 300a is transferred to the central ECU 100 in any case.

[0095] FIG. 9 is a sequence diagram (information processing method, access permission method) when the charger ECU 300b exhibiting fraudulent behavior accesses the camera information service of the camera ECU 300a according to this embodiment.

[0096] First, the zone ECU 200b receives a search message for the camera information service sent from the charger ECU 300b, checks the access policy of the message, and then transfers the message to the other zone ECUs 200a, 200c, 200d and the central ECU 100 (S200).

[0097] The central ECU 100 and the zone ECUs 200a, 200c, and 200d that have received the camera information service search message check the access policy of the received message (S201). The method for checking the access policy is the same as that of step S101 shown in FIG. 8.

[0098] The zone ECUs 200a, 200c, and 200d transfer a search message for the camera information service to their own zones (S202).

[0099] The camera ECU 300a transmits an Offer message for the camera information service to the zone ECU 200a, and the zone ECU 200a transfers the message to the zone ECU 200b (S203). The message is then transferred to the charger ECU 300b. That is, the zone ECU 200b transfers a response from the camera ECU 300a to the charger ECU 300b.

[0100] Next, the charger ECU 300b transmits a message requesting the use of the camera information service to the camera ECU 300a via the zone ECUs 200b and 200a (S204).

[0101] Thereafter, the zone ECUs 200c and 200d transmit to the central ECU 100 a verification result (NG) indicating that the use of the camera information service by the charger ECU 300b violates the access policy (S205).

[0102] Similarly, the zone ECU 200a also transmits to the central ECU 100 the fact that the verification result is a violation of the access policy (NG) (S206).

[0103] The central ECU 100 comprehensively determines the verification results of the access policies received from the zone ECUs 200a, 200c, and 200d, and notifies (transmits) a message (a request to shut off the camera information service) to the corresponding zone ECUs, the zone ECUs 200a and 200b, prohibiting the charger ECU 300b that has violated the access policy from accessing the camera information service (S207). In other words, the central ECU 100 requests the zone ECUs 200a and 200b to shut off the camera information service. In step S207, if the number of policy verification results including access NG (access denied) among the policy verification results is equal to or greater than a threshold, the master policy determination unit 106 of the central ECU 100 transmits a master policy verification result indicating access denial (here, a shutdown request) to the zone ECU 200a connected to the camera ECU 300a and the zone ECU 200b connected to the charger ECU 300b among the multiple zone ECUs 200a, etc.

[0104] In step S207, the master policy determination unit 106 of the central ECU 100 outputs a master policy verification result (in this case, a cut-off request because access was determined to be denied) which is the final determination result of whether or not access is permitted for the camera information service search message received in step S200, based on the verification result of the access policy transmitted from the zone ECUs 200a, 200c, and 200d. The cut-off request is an example of verification information related to the master policy verification result.

[0105] Thereafter, communication relating to the camera information service between the charger ECU 300b and the camera ECU 300a is cut off by the zone ECU 200a or the zone ECU 200b, and the charger ECU 300b is unable to fraudulently use the camera information service.

[0106] In this case, the charger ECU 300b is an example of one electronic control device, and the camera ECU 300a is an example of another electronic control device. The transmission of the search message is an example of access from the charger ECU 300b to the service of the camera ECU 300a.

[0107] The cutoff request in step S207 may be notified (transmitted) to each of a plurality of zone ECUs 200a, etc. including the zone ECUs 200c and 200d.

[0108] FIG. 10 is a flowchart (information processing method, access permission method) showing details of the processing of the master policy determination unit 106 and the policy enforcement unit 107 executed by the central ECU 100 according to this embodiment.

[0109] First, the central ECU 100 receives a SOME / IP-SD message (service Find message or service Offer message) from the in-vehicle network (S300). The service Find message is a message that allows a destination (client side) to find a service provider (server side) that provides the service. The service Find message is a message that includes information about which ECU is searching for which service. The service Offer message is a message that notifies the server side (such as the camera ECU 300a) of information that it possesses (can provide). The service Offer message is a message that includes information about which ECU can provide which service.

[0110] The central ECU 100 checks the provided or requested service ID included in the received SOME / IP-SD message and determines whether the important characteristics of the service related to the received message are safety by referring to the access policy holding unit 108 (S301). The master policy determination unit 106 of the central ECU 100 determines whether the important characteristics of the service ID included in the Service Find message or the Service Offer message are safety based on the access policy shown in Fig. 5. As shown in Fig. 5, the access policy has a one-to-one correspondence between the service ID and the important characteristics.

[0111] In addition, there may be multiple service IDs in the received SOME / IP-SD message, in which case the central ECU 100 may check all service IDs and determine whether or not there are any services that require security.

[0112] Furthermore, for a SOME / IP-SD message containing different important characteristics, the central ECU 100 may divide the message into service IDs and transfer the SOME / IP-SD message. For example, for a SOME / IP-SD message containing service IDs whose important characteristics are different, safety and availability, the central ECU 100 may create a SOME / IP-SD message containing only the service IDs whose important characteristic is availability, and transfer the created message first. Furthermore, the central ECU 100 may check the service policy not for the SOME / IP-SD message but for the SOME / IP message.

[0113] If it is determined that the important characteristic of the service related to the received message is security (Yes in S301), the central ECU 100 checks the access policy and determines whether the source and destination of the service conform to the access policy (S302).

[0114] If it is determined that the next received message matches the access policy (Yes in S302), the central ECU 100 permits the transfer of the message (S303) and ends the process. In step S303, only messages that pass through the central ECU 100 are permitted. As will be described later with reference to FIG. 11, in this case, each zone ECU 200a, etc., individually determines whether the access policy is OK. The message in step S303 is a normal SOME / IP message, and may be, for example, a message sending camera information (image information). The message is a message received after the Service Find message and is not a service discovery message.

[0115] It can also be said that for a service (third service) whose important characteristic is safety, the central ECU 100 allows each of the multiple zone ECUs 200a, etc. to individually determine whether or not to allow access to the service in that zone ECU based on the policy verification result of that zone ECU before the master policy verification result is output.

[0116] If it is determined that the message does not conform to the access policy (No in S302), the central ECU 100 prohibits the transfer of the message (S304) and ends the process.

[0117] If it is determined that the important characteristic of the service related to the received message is not security (No in S301), the central ECU 100 determines whether the important characteristic of the service related to the received message is confidentiality (S305).

[0118] If it is determined that the important characteristic of the service related to the next received message is confidentiality (Yes in S305), the central ECU 100 receives the policy verification results of the zone ECUs 200a, 200b, 200c, and 200d related to the message (S306).

[0119] Furthermore, the central ECU 100 determines whether the number of received policy verification results OK from the zone ECUs 200a, 200b, 200c, and 200d is less than a threshold value (3 in this example) (S307). When confidentiality is required, the central ECU 100 receives the judgment results of the other zone ECUs and comprehensively determines whether or not to allow access, since the data is important. The threshold value used in step S307 is larger than the threshold value used in step S311, but is not limited to this.

[0120] If it is determined that the number of received policy verification results OK from the zone ECUs 200a, 200b, 200c, and 200d is less than three (Yes in S307), the central ECU 100 prohibits the transfer of the message (S304).

[0121] On the other hand, if it is determined that the number of policy verification results OK received from zone ECUs 200a, 200b, 200c, and 200d is three or more (No in S307), the central ECU 100 allows the transfer of the message (S308) and terminates the processing.

[0122] If it is determined that the important characteristic of the service related to the received message is not confidentiality (No in S305), the central ECU 100 allows the transfer of the message because the important characteristic of the service related to the message is availability (S309).

[0123] Next, the central ECU 100 receives the policy verification results of the zone ECUs 200a, 200b, 200c, and 200d regarding the message (S310).

[0124] Thereafter, the central ECU 100 determines whether the number of received policy verification results OK from the zone ECUs 200a, 200b, 200c, and 200d is less than 2 (S311). For example, in steps S205 and S206 shown in FIG. 9, all of the results are NG, so it is determined that the number of received results is 0, that is, less than 2.

[0125] If it is determined that the number of received policy verification results OK from the zone ECUs 200a, 200b, 200c, and 200d is less than two (Yes in S311), the central ECU 100 notifies the zone ECUs 200a, 200b, 200c, and 200d to prohibit communication that violates the access policy for the service (S312), and then ends the process. Step S312 corresponds to step S207 shown in FIG. 9.

[0126] On the other hand, if it is determined that the number of received policy verification results OK from the zone ECUs 200a, 200b, 200c, and 200d is two or more (No in S311), the central ECU 100 ends the process. In this case, the state permitted in step S309 continues. In this way, if the service is one for which availability is required as an important characteristic, the process is executed so that the service is permitted (S309), and if there is any problem (Yes in S311), it is later prohibited (S312).

[0127] The threshold value for the number of received policy verification results OK from the zone ECUs 200a, 200b, 200c, and 200d, which determines the branching of the processing contents of the central ECU 100, is not limited to the value shown in this embodiment, and may be changed depending on the in-vehicle network configuration, the number of zone ECUs, and the content of the message.

[0128] The number of received policy verification results that are OK may include not only the policy verification results of the zone ECUs 200a, 200b, 200c, and 200d, but also the policy verification result of the master policy determination unit 106 of the central ECU 100.

[0129] Although this flowchart shows an example of determining an access policy for a SOME / IP-SD, the target of access restriction is not limited to a SOME / IP-SD message. For example, the target may be a SOME / IP message, a Data Distribution Service (DDS) message, or the like.

[0130] Also, in this flowchart, in step S304, the central ECU 100 prohibits the transfer of the message, i.e., prohibits the transfer of the SOME / IP-SD message, but it may also forward the SOME / IP-SD message and prohibit the transfer of subsequent messages related to the service in question, or it may notify other zone ECUs to prohibit communication outside the access policy.

[0131] 11 is a flowchart (information processing method, access permission method) showing details of the access permission determination process executed by the zone ECU 200a according to this embodiment. The zone ECUs 200b, 200c, and 200d also execute similar processes.

[0132] First, the zone ECU 200a receives a SOME / IP-SD message (a service Find message or a service Offer message) from the in-vehicle network (S400).

[0133] The zone ECU 200a checks the provided or requested service ID included in the received SOME / IP-SD message and determines whether the important characteristics of the service related to the received message are safety by referring to the access policy holding unit 204 (S401). The policy determination unit 202 of the zone ECU 200a determines whether the important characteristics of the service ID included in the service Find message or the service Offer message are safety based on the access policy shown in FIG.

[0134] In addition, there may be multiple service IDs in the received SOME / IP-SD message, in which case the zone ECU 200a may check all service IDs and determine whether or not there are any services that require security.

[0135] Furthermore, for a SOME / IP-SD message containing different important characteristics, the zone ECU 200a may divide the message into service IDs and transfer the SOME / IP-SD message. For example, for a SOME / IP-SD message containing service IDs whose important characteristics are different, safety and availability, the zone ECU 200a may create a SOME / IP-SD message containing only service IDs whose important characteristic is availability and transfer the created message first. Furthermore, the zone ECU 200a may check the service policy for the SOME / IP message rather than for the SOME / IP-SD message.

[0136] If it is determined that the important characteristic of the service related to the received message is security (Yes in S401), the zone ECU 200a checks the access policy and determines whether the source and destination of the service conform to the access policy (S402).

[0137] If the next received message is determined to match the access policy (Yes in S402), the zone ECU 200a permits the transfer of the message (S403) and ends the process. In step S403, only messages that pass through the zone ECU 200a are permitted.

[0138] If it is determined that the received message does not conform to the access policy (No in S402), the zone ECU 200a prohibits the transfer of the message (S404) and ends the process.

[0139] If the zone ECU 200a determines that the important characteristic of the service related to the received message is not security (No in S401), it determines whether the important characteristic of the service related to the received message is confidentiality (S405).

[0140] Next, when it is determined that the important property of the service related to the received message is confidentiality (Yes in S405), the zone ECU 200a transmits the policy verification result related to the message to the central ECU 100 (S406).

[0141] Furthermore, the zone ECU 200a receives the final access permission / denial determination result (master policy verification result) from the central ECU 100, and determines whether the determination result is access denial (NG) (S407).

[0142] When the zone ECU 200a receives an access denial (NG) as the final determination result from the central ECU 100 (Yes in S407), the zone ECU 200a prohibits the transfer of the message (S404).

[0143] On the other hand, if the zone ECU 200a receives an access permission (OK) as the final determination result (No in S407), it permits the transfer of the message (S408) and ends the process.

[0144] If it is determined that the important characteristic of the service related to the received message is not confidentiality (No in S405), the zone ECU 200a allows the transfer of the message because the important characteristic of the service related to the message is availability (S409).

[0145] Next, the zone ECU 200a transmits the policy verification result of the zone ECU 200a regarding the message to the central ECU 100 (S410).

[0146] Thereafter, the zone ECU 200a receives the final decision result of whether access is permitted or denied (master policy verification result) from the central ECU 100, and determines whether the decision result is access denial (NG) (S411).

[0147] If the zone ECU 200a determines that it has received an access denial as the final determination result (Yes in S411), it prohibits communication that violates the access policy for the service (S412) and ends the process.

[0148] On the other hand, if the zone ECU 200a determines that the access is permitted as a final determination result (No in S411), it terminates the process without taking any action. In this case, the state permitted in step S409 continues. In this way, if the service requires availability as an important characteristic, the process is executed so that the access is permitted (S409), and if there is any problem (Yes in S411), it is later prohibited (S412).

[0149] While this flowchart illustrates an example of determining an access policy for a SOME / IP-SD message, the target of access restriction is not limited to a SOME / IP-SD message. It may also apply to a SOME / IP message or a Data Distribution Service (DDS) message. In addition, in step S404 of this flowchart, the zone ECU 200a prohibits the transfer of the message, i.e., prohibits the transfer of the SOME / IP-SD message. However, it is also possible to transfer the SOME / IP-SD message and prohibit the transfer of subsequent messages related to the service.

[0150] 12 is a flowchart (information processing method, access permission method) showing a process in which the master policy determination unit 106 of the central ECU 100 according to this embodiment changes the important characteristics of each service stored in the access policy holding unit 108 in accordance with the vehicle state held in the vehicle state holding unit 109. The policy determination units 202 of the zone ECUs 200a, 200b, 200c, and 200d also perform similar processes.

[0151] First, the central ECU 100 receives a message from the in-vehicle network and detects a change in the vehicle state from the communication content (S500). In step S500, the central ECU 100 determines whether the vehicle state has changed.

[0152] The central ECU 100 determines whether the running state of the vehicle has changed (has changed) while the vehicle is stopped (S501).

[0153] If it is determined that the vehicle's running state has changed while the vehicle is stopped (Yes in S501), the central ECU 100 changes the important characteristic of the communication for the service related to charger control to safety (for example, from availability to safety) (S502), and proceeds to step S507.

[0154] If it is determined that the running state of the vehicle has not changed while the vehicle is stopped (No in S501), the central ECU 100 determines whether the running state of the vehicle has changed (changed) while the vehicle is running (S503).

[0155] If it is determined that the vehicle's driving condition has changed while driving (Yes in S503), the central ECU 100 changes the important characteristic of communication for services related to brake control to safety (S504) and proceeds to step S507.

[0156] If it is determined that the vehicle state has not changed during driving (No in S503), the central ECU 100 determines whether the automatic driving mode of the vehicle state has changed to ON (S505). That is, in step S505, it is determined whether the vehicle state has changed during automatic driving.

[0157] If it is determined that the vehicle state's autonomous driving mode has changed to ON (Yes in S505), the central ECU 100 changes the important characteristic of communication for services related to brake control to availability (for example, from safety to availability) (S506) and proceeds to step S507.

[0158] Next, the central ECU 100 transmits information including the changed important characteristic to each zone ECU 200a, etc. (S507). The central ECU 100 may transmit an access policy including the changed important characteristic to each zone ECU 200a, etc. Then, the central ECU 100 ends the process.

[0159] On the other hand, if it is determined that the autonomous driving mode of the vehicle state has not changed to ON (No in S505), the central ECU 100 ends the processing.

[0160] Regarding the change of the important characteristics, the contents of the access policy holding unit 108 may be changed as shown in this flowchart, or the important characteristics may be changed by referring to the vehicle state in the vehicle state holding unit 109 at the timing of reference to the access policy holding unit 108 in Figure 10.

[0161] As a result, even for the same service ID, the important characteristics change depending on the vehicle state, so the result of the access permission determination can be made different depending on the vehicle state, and therefore the result of the access permission determination can be made according to the vehicle state at that time.

[0162] The central ECU 100 may increase or decrease the threshold value for denying access depending on the vehicle state and the service of the vehicle 10. For example, the central ECU 100 may set the threshold value so that the threshold value increases in the order of the vehicle state of the vehicle 10 being stopped, moving, and automatically driving.

[0163] FIG. 13 is a flowchart (information processing method, access permission method) showing the processing that is performed when the master policy determination unit 106 of the central ECU 100 according to this embodiment collects the policy verification results of the zone ECUs 200a, 200b, 200c, and 200d and there is a zone ECU that transmits a verification result that differs from the other zone ECUs.

[0164] First, when the central ECU 100 receives the policy verification results from each zone ECU 200a, etc., in step S306 or step S310 of the flowchart in Fig. 10, it determines whether there is a zone ECU that returns a different policy verification result (S600). That is, the central ECU 100 determines whether it has received different policy verification results from each zone ECU.

[0165] If there is a zone ECU that returns a different policy verification result (Yes in S600), the central ECU 100 requests the zone ECU that returned the different policy verification result to transmit the version of the access policy (S601). The central ECU 100 requests the zone ECU that returned the different policy verification result to transmit the version of the access policy. The version of the access policy is an example of information related to the access policy. The information related to the access policy may be, for example, the date and time when the access policy was updated.

[0166] The central ECU 100 may request the version of the access policy from all zone ECUs, instead of requesting the version of the access policy from zone ECUs that have returned different policy verification results.

[0167] Next, when the central ECU 100 receives the version of the access policy from the zone ECU that returned a different policy verification result, the central ECU 100 determines whether the version information of the received access policy differs from the version information of the access policy held by the central ECU 100 itself (S602). In step S602, for example, it may be determined whether the access policies held by each zone ECU 200a, etc. are synchronized.

[0168] Instead of comparing the version of the access policy with the version information of the access policy that it holds, the central ECU 100 may compare it with the version of the access policy of another zone ECU, or the central ECU 100 may hold a list of version information of access policies that are expected to be used in advance and check whether the version information of the access policy of the zone ECU in question matches the version information of the access policy that is listed in the list.

[0169] If it is determined that the version information of the received access policy is different from the version information of the access policy held by the central ECU 100 itself (Yes in S602), the central ECU 100 determines that the zone ECU is using an access policy different from the expected one, updates the access policy of the zone ECU (S603), and ends the processing. For example, the central ECU 100 may transmit the access policy held by itself to each zone ECU 200a, etc. (or to zone ECUs with different access policies).

[0170] On the other hand, if it is determined that the version information of the received access policy is the same as the version information of the access policy held by the central ECU 100 itself (No in S602), the central ECU 100 determines that the corresponding zone ECU is exhibiting unauthorized behavior, and ignores (or reduces the weight of) the verification results (policy verification results) from the corresponding zone ECU from the next time onwards (S604), and terminates the processing. Ignoring may mean not performing any processing on the policy verification results even if received from the corresponding zone ECU. Ignoring may also mean, for example, not using the policy verification results to determine the master policy verification result even if received.

[0171] If it is determined that there is no zone ECU that returns a different verification result (No in S600), the central ECU 100 ends the process.

[0172] In addition, if a zone ECU exhibiting fraudulent behavior is found, the central ECU 100 may notify an external server that a zone ECU exhibiting fraudulent behavior is found, or may record the abnormality as a log.

[0173] [Other Modifications] Next, modifications other than those described above that are used in the in-vehicle network system according to this embodiment, and specific examples of images that are used for analysis when an unauthorized zone ECU is present, etc. will be described.

[0174] [Modification 1] Fig. 14 is a diagram showing the overall configuration of an in-vehicle network system according to this modification, in which the same components as those shown in Fig. 1 are denoted by the same reference numerals.

[0175] The in-vehicle network system mounted on the vehicle 20 includes a central ECU 1000, zone ECUs 2000a, 2000b, 2000c, and 2000d, a camera ECU 300a, a charger ECU 300b, a brake ECU 300c, and a motor ECU 300d.

[0176] The central ECU 1000 and the zone ECUs 2000a, 2000b, 2000c, and 2000d will be described below.

[0177] Fig. 15 is a block diagram showing the functional configuration of central ECU 1000 according to this modification. The information stored in vehicle state storage unit 1109 is different from that of central ECU 100 of the embodiment shown in Fig. 2, and a master policy determination unit 1106 has additional functions compared to master policy determination unit 106. The information stored in vehicle state storage unit 1109 will be described in detail later with reference to Fig. 17.

[0178] 16 is a block diagram showing the functional configuration of a zone ECU 2000a according to this modification, which includes an integrity verification unit 206 and an in-vehicle network intrusion detection unit 207 added as components to the zone ECU 200a shown in FIG.

[0179] The integrity verification unit 206 verifies that the functional configuration of the zone ECU 2000a has not been tampered with. Specifically, the integrity verification unit 206 verifies that the software or data of the zone ECU 2000a has not been tampered with by comparing a hash value calculated from the software or data constituting the zone ECU 2000a with a hash value stored in advance. The integrity verification unit 206 periodically or irregularly verifies the integrity of the software or data of the zone ECU 2000a (integrity verification) while the zone ECU 2000a is running. The integrity verification result is notified to the central ECU 1000 via the in-vehicle network communication unit 201.

[0180] The in-vehicle network intrusion detection unit 207 monitors the in-vehicle network communications received by the zone ECU 2000a and detects whether any abnormal communications have occurred. Specifically, the in-vehicle network intrusion detection unit 207 detects, as abnormal communications, messages sent to unexpected senders or destinations, messages received at a higher frequency than normal, port scan communications, diagnostic communications at improper times, and the like.

[0181] When the in-vehicle network intrusion detection unit 207 detects abnormal communication, it notifies the central ECU 1000 of the occurrence of the abnormality.

[0182] Similarly, the zone ECUs 2000b, 2000c, and 2000d may also include the integrity verification unit 206 and the in-vehicle network intrusion detection unit 207, or may include only one of them. Furthermore, it is sufficient that at least one of the zone ECUs 2000a, 2000b, 2000c, and 2000d includes at least one of the integrity verification unit 206 and the in-vehicle network intrusion detection unit 207.

[0183] FIG. 17 is a diagram showing an example of the vehicle state stored in the vehicle state storage unit 1109 of the central ECU 1000 according to this modification.

[0184] 17 stores the integrity verification result and time and the in-vehicle network intrusion detection result (the result of the intrusion detection system) notified from the zone ECUs 2000a, 2000b, 2000c, and 2000d in addition to the information stored in the vehicle state of FIG. 6. The in-vehicle network intrusion detection result is the detection result of the in-vehicle network intrusion detection system.

[0185] The integrity verification result is stored for each zone ECU together with the time. In FIG. 17 , the integrity verification result for zone ECU 2000a is OK, indicating that the software or data has not been tampered with, and the last verification time is 1:05 PM. The integrity verification result for zone ECU 2000b is OK, indicating that the software or data has not been tampered with, and the last verification time is 1:05 PM. The integrity verification result for zone ECU 2000c is OK, indicating that the software or data has not been tampered with, and the last verification time is 1:10 PM. The integrity verification result for zone ECU 2000d is OK, indicating that the software or data has not been tampered with, and the last verification time is 12:30 PM.

[0186] The results of the in-vehicle network intrusion detection system are also stored for each zone ECU. The intrusion detection result of the in-vehicle network system of zone ECU 2000a is OK, meaning that no abnormality has been detected. The intrusion detection result of the in-vehicle network system of zone ECU 2000b is OK, meaning that no abnormality has been detected. The intrusion detection result of the in-vehicle network system of zone ECU 2000c is OK, meaning that no abnormality has been detected. The intrusion detection result of the in-vehicle network system of zone ECU 2000d is OK, meaning that no abnormality has been detected.

[0187] FIG. 18 is a flowchart showing a process for determining the threshold values ​​used in steps S307 and S311 in the flowchart of FIG. 10 in the master policy determination unit 1106 of the central ECU 1000 according to this modification.

[0188] The timing for determining the threshold is not particularly limited, and for example, the threshold may be calculated each time it is referenced (i.e., this process may be executed immediately before step S307 or step S311), or a process for determining the threshold may be performed in advance.

[0189] The central ECU 1000 determines whether the important characteristic of the service for which the access policy is to be verified is confidentiality (S700).

[0190] If it is determined that confidentiality is the important characteristic of the service for which the access policy is to be verified (Yes in S700), the central ECU 1000 sets the threshold N for the number of receptions for which the policy verification results are OK received from the zone ECUs 2000a, 2000b, 2000c, and 2000d to "the number of zone ECUs arranged in the in-vehicle network system minus 1" (4 - 1 = 3 in this modified example) (S701). The central ECU 1000 sets the value of the threshold N for denying access to the service (second service) for which confidentiality is the important characteristic to a value lower than a predetermined value. The predetermined value here is, for example, but not limited to, a value obtained by subtracting a predetermined number from the number of zone ECUs. The threshold N set in step S701 is the threshold used in step S307 of FIG. 10.

[0191] On the other hand, if it is determined that confidentiality is not an important characteristic of the service for which the access policy is to be verified (No in S700), the central ECU 1000 sets the threshold N, which is the number of receptions for which the policy verification results are OK, received from the zone ECUs 2000a, 2000b, 2000c, and 2000d, to "the number of zone ECUs arranged in the in-vehicle network system minus 2" (4 - 2 = 2 in this modification) (S702). The central ECU 1000 sets the value of the threshold N, which denies access to a service (first service) whose important characteristic is not confidentiality (e.g., availability), to a value higher than a predetermined value. The predetermined value here is, for example, but not limited to, a value obtained by subtracting a predetermined number from the number of zone ECUs. The threshold N set in step S702 is the threshold used in step S311 of FIG. 10 .

[0192] Note that the threshold value N set in steps S701 and S702 is not limited to the value shown in Fig. 18. The threshold value N set in step S701 may be set to a value relatively higher than the threshold value N set in step S702.

[0193] Next, the central ECU 1000 checks the vehicle state, checks the integrity verification results of the zone ECUs 2000a, 2000b, 2000c, and 2000d, and determines whether there is any zone ECU whose integrity verification has passed within the last five minutes (S703). Note that five minutes is an example and is not limiting.

[0194] If it is determined that there is a zone ECU whose integrity verification has been successful within the last five minutes (Yes in S703), the central ECU 1000 sets (changes) the weight of the policy verification result (access OK / NG) received from the corresponding zone ECU to 2 (e.g., from 1 to 2) (S704). The policy determination result of a zone ECU for which the result of the determination in step S703 is Yes is more reliable than the policy determination result of a zone ECU for which the result of the determination in step S703 is No, and therefore the weight is increased. In this way, by setting the weight of one zone ECU under normal circumstances to 1 and the weight of a zone ECU for which the policy verification result is OK received from a zone ECU whose integrity verification has been successful to 2, the master policy determination unit 1106 counts the number of received policy verification results that are OK so that receiving a policy verification result that is OK from a zone ECU whose integrity verification has been successful is considered to be the same as receiving two policy verification results that are OK.

[0195] The weight is not limited to being increased from 1 to 2, but may be any value greater than 1.

[0196] If it is determined that there is no zone ECU whose integrity verification has been successful within the last five minutes (No in S703), the central ECU 1000 does nothing in particular. Note that if the result in step S703 is No, the central ECU 1000 may lower the weight of the zone ECU.

[0197] In this way, the central ECU 1000 may increase or decrease the weight of the policy verification result received from a zone ECU based on the result of the integrity verification received from the zone ECU.

[0198] Next, the central ECU 1000 checks the vehicle state and determines whether there is a zone ECU in which an abnormality has been detected by the in-vehicle network intrusion detection system (S705).

[0199] If it is determined that a zone ECU that has detected an abnormality in the in-vehicle network intrusion detection system exists (Yes in S705), the central ECU 1000 sets the weight of the policy verification result by the corresponding zone ECU to 0 (zero), subtracts 1 from the current threshold value N (S706), and ends the processing. By subtracting 1 from the current threshold value N, it is possible to set a threshold value appropriate for the case where a zone ECU with a weight of 0 exists.

[0200] If the answer to step S705 is Yes, the central ECU 1000 is not limited to setting the weight of the policy verification result to 0, but may simply lower the weight from the current value.

[0201] In step S706, it is sufficient to at least lower the weight of the policy verification result.

[0202] On the other hand, if it is determined that there is no zone ECU that has detected an abnormality in the in-vehicle network intrusion detection system (No in S705), the central ECU 1000 ends the process. Note that if the result in step S705 is No, the central ECU 1000 may increase the weight of the zone ECU.

[0203] In this way, when the central ECU 1000 receives from a zone ECU that abnormal communication has been detected, the central ECU 1000 may decrease the weight of the policy verification result received from that zone ECU.

[0204] As a result, when a Service Find message is next received, the processing shown in FIG. 10 and the like are executed using the thresholds and weights updated by the processing shown in FIG.

[0205] If there is a zone ECU whose integrity verification result is NG, the weight of the policy verification result of that zone ECU may be set to zero.

[0206] In addition, although an example has been shown in which the weight of the policy verification result of a zone ECU that has detected an abnormality in the in-vehicle network intrusion detection system is set to zero, the weight of the policy verification result of the zone ECU in question does not have to be set to zero. For example, the threshold N may be increased for messages sent from an ECU located in the zone where the abnormality was detected. This allows for more careful judgment of communications sent from an ECU located in the network where an abnormality has occurred, thereby improving the security of the in-vehicle network.

[0207] [Variant 2] Figure 19 is a flowchart (information processing method, access permission method) showing the processing that is performed when the master policy determination unit 106 of the central ECU 100 according to this variant collects the policy verification results of the zone ECUs 200a, 200b, 200c, and 200d and there is a zone ECU that transmits a verification result that is different from the other zone ECUs.

[0208] 19 shows a flowchart obtained by adding step S800 to the flowchart shown in FIG. 13 and replacing step S604 with step S801.

[0209] First, the central ECU 100 acquires the policy verification results from each zone ECU 200a, etc. (S800) Step S800 corresponds to, for example, step S306 or S310 shown in FIG.

[0210] If it is determined that the version information of the received access policy is the same as the version information of the access policy held by the central ECU 100 itself (No in S602), the central ECU 100 transmits to an external server information indicating that an inconsistency has occurred in the policy verification result (S801). Information indicating that an inconsistency has occurred in the policy verification result is an example of verification information related to the master policy verification result. Furthermore, transmitting to an external server information indicating that an inconsistency has occurred in the policy verification result is an example of outputting verification information.

[0211] If the answer to step S602 is YES, the central ECU 100 may transmit at least one of the policy verification result and the access policy version information to an external server as verification information related to the master policy verification result. The access policy version information is an example of information for identifying a specific access policy.

[0212] This allows the verification information to be displayed on a display device connected to an external server, for example, to a supervisor who monitors the in-vehicle network system.

[0213] 20 shows an example of an analysis screen when the central ECU 100 notifies an external server of the situation when a zone ECU with a different policy verification result is found, and the external server determines the situation. FIG. 20 shows an example of the displayed verification information.

[0214] 20 shows the IP address information of the ECU that made the service request when an inconsistency occurred in the policy verification result, and the result of the service that was attempted to be accessed (in the example of FIG. 20, the brake control function). Furthermore, a screen may be displayed that lists the verification results (policy verification results), software versions (SW versions), and access policy versions (policy versions) for the central ECU 100 and each of the zone ECUs 200a, 200b, 200c, and 200d. In FIG. 20, although all the ECUs use the same policy version, only the zone ECU 200b returned a verification result of NG, indicating that an inconsistency occurred in the policy verification result.

[0215] [Effects, etc.] Below, examples of technologies that can be obtained from the contents of the present disclosure will be given, and effects, etc. that can be obtained from the technologies will be described.

[0216] (Technology 1) An information processing method executed by an information processing device in a control network system, the control network system including a plurality of electronic control devices each capable of executing services including execution of predetermined processing and capable of accessing each other for services, and a plurality of edge access permission devices each determining whether to allow or deny the access based on a predetermined access policy, the information processing method obtaining a policy verification result including a determination result of whether to allow or deny the access from each of the plurality of edge access permission devices, and outputting verification information regarding a master policy verification result including a final determination result of whether to allow or deny the access based on the policy verification result from each of the plurality of edge access permission devices.

[0217] In the above embodiment, the access permission device is the central ECU 100, and the edge access permission devices are the zone ECUs 200a, 200b, 200c, and 200d.

[0218] Conventionally, this type of access permission device determines whether or not to grant access at a single access policy verification point. However, there is a possibility that an attacker can circumvent access policy verification by tampering with the access policy or program. Therefore, an access permission device according to one aspect of the present disclosure verifies distributed access policies at multiple verification points to make a final access permission determination. This allows for a highly reliable access permission determination, thereby maintaining the security of the control network system. In other words, when the access permission device is applied to an object (e.g., a vehicle) in which a control network system is installed, a secure control network system can be realized while maintaining the security of the object.

[0219] (Technology 2) The information processing method according to Technology 1, wherein the verification information is output to a display device, thereby displaying the verification information on the display device.

[0220] According to this, by displaying the verification information on the display device, the administrator of the control network system can be informed of the master policy verification result.

[0221] (Technology 3) This is an information processing method according to Technology 2, wherein the verification information includes information identifying the predetermined access policy held by each of the plurality of edge access permission devices, and the policy verification result of each of the plurality of edge access permission devices.

[0222] This allows the administrator of the control network system to know whether an abnormality has occurred in the edge access permission device, using information that identifies a specific access policy and the policy verification result.

[0223] (Technology 4) In the information processing method according to Technology 3, when an inconsistency occurs in the policy verification results from the plurality of edge access permission devices, the verification information is displayed on the display device.

[0224] This allows the administrator of the control network system to be notified when an inconsistency occurs in the policy verification results.

[0225] (Technology 5) The information processing method according to any one of Technologies 1 to 4, wherein the access includes access from one of the plurality of electronic control devices to a service of another of the plurality of electronic control devices, and when the number of policy verification results from each of the plurality of edge access permission devices that include an access denial is equal to or greater than a threshold, the master policy verification result indicating the access denial is transmitted to an edge access permission device connected to the one of the plurality of edge access permission devices and to an edge access permission device connected to the other of the plurality of electronic control devices. The access denial threshold is a threshold for the number of times that a policy verification result indicating a denial of access is received.

[0226] The service can be accessed by an electronic control unit via, for example, SOME / IP communication. When an electronic control unit transmits a message requesting a service that is not permitted, the access policy is verified by multiple zone ECUs 200a, etc., and if the verification result is equal to or exceeds a threshold value, which results in access denial, the message is discarded and access to the service is denied.

[0227] This allows the zone ECU to control access to services based on the final judgment result made based on the verification results of multiple access policies, thereby keeping the control network system safe.

[0228] (Technology 6) The information processing method according to Technology 5, wherein if the number of policy verification results including access denial is equal to or greater than a threshold, the master policy verification result is transmitted to each of the plurality of edge access permission devices.

[0229] According to this, the master policy verification result is transmitted to each of the plurality of edge access permission devices, so that if there is a zone ECU that is operating abnormally, that information can be supplied.

[0230] (Technology 7) An information processing method according to any one of techniques 1 to 4, wherein the access policy includes information regarding either or both of the electronic control devices among the plurality of electronic control devices that are permitted to access the service and the electronic control devices among the plurality of electronic control devices that are permitted to provide the service.

[0231] According to this, it is possible to determine whether to allow access by using an access policy that includes at least one of electronic control devices that are permitted to access the service and electronic control devices that are permitted to provide the service.

[0232] (Technology 8) The service includes a first service that requires availability, and the information processing method is an information processing method described in Technology 5 or 6, in which the threshold value for denying access to the first service is increased to a predetermined value.

[0233] This makes it possible to reduce the impact of infringement of availability due to erroneous access denials for services that require availability of data communications, thereby ensuring the availability of the network system while maintaining security.

[0234] (Technology 9) The information processing method according to Technology 8, wherein the first service includes sending and receiving sensor data.

[0235] According to this, when the first service includes the transmission and reception of sensor data, it is possible to ensure the availability of the network system while maintaining security.

[0236] (Technology 10) An information processing method according to any one of Techniques 5 to 9, wherein the service includes a second service that requires confidentiality, and the information processing method is such that the threshold value for denying access to the second service is set lower than a predetermined value.

[0237] This allows careful access decisions to be made for services that require strict management of data disclosure destinations, thereby maintaining security.

[0238] (Technology 11) The information processing method according to Technology 10, wherein the second service includes exchanging data related to personal information or confidential information.

[0239] This makes it possible to maintain the security of the control network system when the second service includes sending and receiving data.

[0240] (Technology 12) The service includes a third service that requires security, and the information processing method is an information processing method described in any of Technologies 1 to 11, in which, before the master policy verification result is output for the third service, each of the plurality of edge access permission devices individually allows the edge access permission device to determine whether or not to allow access to the service based on the policy verification result of the edge access permission device.

[0241] This makes it possible to grant access to services that require real-time control while minimizing the processing delay that occurs when waiting for the results of distributed access policy verification, thereby maintaining the security and real-time capabilities of the network system.

[0242] (Technology 13) The information processing method according to Technology 12, wherein the third service includes a service related to control of an actuator.

[0243] This makes it possible to maintain the security and real-time performance of the network system when the third service relates to the control of an actuator.

[0244] (Technology 14) The control network system is an in-vehicle network system installed in a vehicle, and the information processing method is the information processing method described in Technology 5, in which the threshold value for denying access is increased or decreased depending on the vehicle state of the vehicle and the service.

[0245] This makes it possible to appropriately change the method of determining whether or not access is permitted for services whose priority characteristics change depending on the vehicle's driving conditions, thereby improving the security of the network system.

[0246] (Technology 15) The information processing method according to Technology 14, wherein the vehicle state includes one or more of a driving state, a charging state, an update state, a diagnostic mode state, and an autonomous driving mode.

[0247] This allows a threshold value to be set according to any one of the driving state, charging state, update state, diagnostic mode state, and autonomous driving mode.

[0248] (Technology 16) An information processing method according to any one of Technologies 1 to 15, wherein at least one edge access permission device among the plurality of edge access permission devices is configured to be able to perform integrity verification to verify that its own software or data has not been tampered with, and the information processing method increases or decreases the weight of the policy verification result received from the at least one edge access permission device based on the result of the integrity verification received from the at least one edge access permission device.

[0249] According to this, the access policy verification result by the edge access permission device whose safety has been verified is weighted and evaluated, thereby making it possible to efficiently determine whether or not to permit access.

[0250] (Technology 17) An information processing method according to any one of Technologies 1 to 16, wherein at least one edge access permission device among the plurality of edge access permission devices is configured to be able to detect anomalous communication, and the information processing method, upon receiving from the at least one edge access permission device that the anomalous communication has been detected, reduces a weight of the policy verification result received from the at least one edge access permission device.

[0251] According to this, when abnormal communication is detected, the weight of the policy verification result received from the edge access permission device is reduced, thereby making it possible to efficiently determine whether or not to permit access.

[0252] (Technology 18) An information processing method according to any one of Technologies 1 to 17, in which, if there is an edge access permission device among the plurality of edge access permission devices that transmits the policy verification result different from that of the other edge access permission devices, a request is made for transmission of information regarding the access policy held by that edge access permission device.

[0253] Since the policy verification results are originally expected to be the same for all edge access permission devices, this makes it possible to detect edge access permission devices that are operating differently from expectations and to investigate the cause, thereby improving the security of the network system.

[0254] (Technology 19) An information processing device in a control network system, the control network system including a plurality of electronic control devices each capable of executing services including execution of predetermined processing and capable of mutually accessing each other for the services, and a plurality of edge access permission devices each determining whether or not to allow the access based on a predetermined access policy, the information processing device including: an acquisition unit that acquires a policy verification result including a determination result of whether or not to allow the access from each of the plurality of edge access permission devices; and an output unit that outputs verification information regarding a master policy verification result including a final determination result of whether or not to allow the access based on the policy verification result from each of the plurality of edge access permission devices.

[0255] Such an information processing device provides the same effects as the information processing method according to one aspect of the present disclosure.

[0256] (Technology 20) A program for causing a computer to execute the information processing method according to any one of technologies 1 to 18.

[0257] Such a program provides the same effects as the information processing method according to one aspect of the present disclosure.

[0258] Note that the general or specific aspects of the present disclosure may be realized as a system, an apparatus, 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 as any combination of a system, an apparatus, a method, an integrated circuit, a computer program, and a recording medium.

[0259] Other Embodiments Although the present disclosure has been described above based on the embodiments, the present disclosure is not limited to the above-described embodiments.

[0260] For example, the control network system of the present disclosure is not limited to an in-vehicle network system, and may include other mobility network systems and / or control network systems. Furthermore, the communication standard for communications performed in such systems is not particularly limited. Furthermore, the architecture of the in-vehicle communication network system is not limited to the example shown in FIG. 1 .

[0261] Furthermore, the object in which the control network system is installed is not limited to a mobile object such as a vehicle, but may be a non-mobile object such as a facility. A facility is, for example, an object in which a home network system, which is an example of a control network system, is installed. The facility may be, for example, a house, a hospital, a building, a nursing home, a school, etc.

[0262] Although the example in which the policy determination unit and the policy enforcement unit are provided in the zone ECU has been described, the policy determination unit and the policy enforcement unit may be provided in a location other than the zone ECU. For example, the policy determination unit and the policy enforcement unit may be provided in an ECU, a network switch, or a network gateway. Furthermore, the master policy determination unit does not have to be provided in the central ECU. For example, the master policy determination unit may be provided on an ECU that has an execution environment with a different security level from that of normal applications.

[0263] In addition, if there is an ECU that has an access policy holding unit and a policy judgment unit that cannot receive a policy verification target message, such as a camera information service search message in the above embodiment, because the message is not broadcast, the target message may be forwarded to the ECU to request policy verification.

[0264] In addition, in the above embodiment, an example was described in which each zone ECU that receives a search message such as a camera information service verifies the access policy, but this is not limited to this, and it is sufficient that at least two or more zone ECUs out of the multiple zone ECUs that receive the search message verify the access policy.

[0265] The present disclosure may also be realized as an access permission device mounted on an object, the object having an ECU in which the access permission device is provided and one or more zone ECUs (e.g., multiple zone ECUs 200 a, etc.) that are managed by the ECU and control equipment mounted on the object, and the access permission device includes: an acquisition unit (e.g., a center communication unit) that, when an access request (e.g., a request for access to a service) is made from an arbitrary sender (or provider) in the object to an arbitrary destination (or provider) in the object, acquires, in each of the one or more zone ECUs, a policy verification result that is a determination result on whether or not access is permitted for the access request based on a predetermined access policy; and a master policy determination unit that determines whether or not access is permitted for the access request based on the policy verification result acquired from each of the one or more zone ECUs.

[0266] The present disclosure may also be realized as an access permission method executed by an access permission device mounted on an object, the object having an ECU in which the access permission device is provided and one or more zone ECUs (e.g., multiple zone ECUs 200 a, etc.) that are managed by the ECU and control equipment mounted on the object, the access permission method including, when there is an access request (e.g., a request for access to a service) from an arbitrary sender (or provider) in the object to an arbitrary destination (or provider) in the vehicle, acquiring, in each of the one or more zone ECUs, a policy verification result that is a determination result on whether or not access is permitted for the access request based on a predetermined access policy, and determining whether or not access is ultimately permitted for the access request based on the policy verification result acquired from each of the one or more zone ECUs.

[0267] In addition, in the above embodiment, an example was described in which the object on which the control network system is installed is a moving object such as a vehicle, but this is not limited to this and the control network system may also be installed on a stationary object that does not move.

[0268] Furthermore, the communication method and communication standard between the devices in the above-described embodiments are not particularly limited. Wireless communication or wired communication may be performed between the devices. Furthermore, wireless communication and wired communication may be combined between the devices.

[0269] Furthermore, for example, all of the numbers used above are examples for specifically explaining the present disclosure, and the embodiments of the present disclosure are not limited to the exemplified numbers.

[0270] Furthermore, for example, the division of functional blocks in the block diagram is merely an example, and multiple functional blocks may be realized as a single functional block, one functional block may be divided into multiple blocks, or some functions may be moved to another functional block.Furthermore, the functions of multiple functional blocks having similar functions may be processed in parallel or in time-sharing by a single piece of hardware or software.

[0271] Furthermore, for example, 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. Furthermore, some of the steps may be performed simultaneously (in parallel) with other steps.

[0272] Furthermore, for example, the components included in each device described in the above embodiments may be distributed among multiple devices in any manner without departing from the spirit of the present disclosure.

[0273] In the above-described embodiment, the processing performed by a specific processing unit may be performed by another processing unit. The order of multiple processing operations may be changed, or multiple processing operations may be performed in parallel.

[0274] In the above-described embodiments, each component (each processing unit) may be realized by executing a software program suitable for that component. Each component may be realized by a program execution unit such as a CPU (Central Processing Unit) or a processor reading and executing a software program recorded on a recording medium such as a hard disk or semiconductor memory.

[0275] Furthermore, each component may be realized by hardware. Each component may be a circuit (or integrated circuit). These circuits may form a single circuit as a whole, or each may be a separate circuit. Furthermore, each of these circuits may be a general-purpose circuit or a dedicated circuit.

[0276] Furthermore, the general or specific aspects of the present disclosure may be realized as a system, an apparatus, a method, an integrated circuit, a computer program, or a non-transitory recording medium such as a computer-readable CD-ROM, or as any combination of a system, an apparatus, a method, an integrated circuit, a computer program, and a recording medium.

[0277] In addition, this disclosure also includes forms obtained by applying various modifications to each embodiment that a person skilled in the art would think of, or forms realized by arbitrarily combining the components and functions of each embodiment within the scope of this disclosure.

[0278] The present disclosure is applicable to a control device that controls a vehicle.

[0279] 10, 20 Vehicle 100, 1000 Central ECU (information processing device, access permission device) 101 Center communication unit (acquisition unit, output unit) 102 Vehicle control application unit 103 Driver application unit 104 Autonomous driving application unit 105, 201 In-vehicle network communication unit (output unit) 106, 1106 Master policy determination unit 107, 203 Policy enforcement unit 108, 204 Access policy storage unit 109, 205, 1109 Vehicle state storage unit 110 User information storage unit 200a, 200b, 200c, 200d, 2000a, 2000b, 2000c, 2000d Zone ECU (edge ​​access permission device) 202 Policy determination unit 206 Integrity verification unit 207 In-vehicle network intrusion detection unit 300a Camera ECU 300b Charger ECU 300c Brake ECU 300d Motor ECU 301 Application unit 302 Communication unit

Claims

1. An information processing method executed by an information processing device in a control network system, the control network system including a plurality of electronic control devices each capable of executing services including the execution of predetermined processing and capable of accessing each other for the services, and a plurality of edge access permission devices each determining whether or not to allow the access based on a predetermined access policy, the information processing method comprising the steps of: obtaining a policy verification result including a determination result of whether or not to allow the access from each of the plurality of edge access permission devices; and outputting verification information regarding a master policy verification result including a final determination result of whether or not to allow the access based on the policy verification result from each of the plurality of edge access permission devices.

2. The information processing method according to claim 1, further comprising the step of outputting the verification information to a display device, thereby causing the display device to display the verification information.

3. The information processing method according to claim 2, wherein the verification information includes information for identifying the predetermined access policy held by each of the plurality of edge access permission devices, and a result of the policy verification for each of the plurality of edge access permission devices.

4. The information processing method according to claim 3, further comprising the step of: displaying said verification information on said display device when an inconsistency occurs in said policy verification results from each of said plurality of edge access permission devices.

5. The information processing method according to any one of claims 1 to 4, wherein the access includes access from one of the plurality of electronic control devices to a service of another of the plurality of electronic control devices, and wherein, when the number of policy verification results from each of the plurality of edge access access devices that include an access denial is equal to or greater than a threshold, the master policy verification result indicating access denial is transmitted to an edge access access permission device connected to the one of the plurality of edge access access devices and to an edge access access permission device connected to the other of the plurality of electronic control devices.

6. The information processing method according to claim 5, further comprising the step of transmitting the master policy verification result to each of the plurality of edge access permission devices when the number of policy verification results including access denial is equal to or greater than a threshold value.

7. An information processing method according to any one of claims 1 to 4, wherein the access policy includes information regarding either or both of electronic control devices among the plurality of electronic control devices that are permitted to access the service and electronic control devices among the plurality of electronic control devices that are permitted to provide the service.

8. The information processing method according to claim 5, wherein the service includes a first service that requires availability, and the information processing method further comprises increasing the threshold value for denying access to the first service to a predetermined value.

9. The information processing method according to claim 8, wherein the first service includes transmitting and receiving sensor data.

10. The information processing method according to claim 5, wherein the service includes a second service that requires confidentiality, and the information processing method further comprises setting the threshold value for denying access to the second service lower than a predetermined value.

11. The information processing method according to claim 10, wherein the second service includes transmitting and receiving data related to personal information or confidential information.

12. An information processing method according to any one of claims 1 to 4, wherein the service includes a third service for which security is required, and the information processing method permits each of the plurality of edge access permission devices to individually determine whether or not to allow access to the third service based on the policy verification result of that edge access permission device before the master policy verification result is output.

13. The information processing method according to claim 12, wherein the third service includes a service related to control of an actuator.

14. The information processing method according to claim 5, wherein the control network system is an in-vehicle network system mounted in a vehicle, and the information processing method increases or decreases the numerical value of the threshold for denying the access depending on the vehicle state of the vehicle and the service.

15. The information processing method according to claim 14, wherein the vehicle state includes one or more of a driving state, a charging state, an update state, a diagnostic mode state, and an autonomous driving mode.

16. An information processing method according to any one of claims 1 to 4, wherein at least one of the plurality of edge access permission devices is configured to be capable of performing integrity verification to verify that its own software or data has not been tampered with, and the information processing method increases or decreases the weight of the policy verification result received from the at least one edge access permission device based on the result of the integrity verification received from the at least one edge access permission device.

17. An information processing method according to any one of claims 1 to 4, wherein at least one edge access permission device among the plurality of edge access permission devices is configured to be capable of detecting anomalous communication, and the information processing method reduces a weight of the policy verification result received from the at least one edge access permission device upon receiving a notification from the at least one edge access permission device that the anomalous communication has been detected.

18. An information processing method according to any one of claims 1 to 4, further comprising the step of, if there is an edge access permission device among the plurality of edge access permission devices that transmits a policy verification result that is different from the other edge access permission devices, requesting transmission of information regarding the access policy held by that edge access permission device.

19. An information processing device in a control network system, wherein the control network system includes a plurality of electronic control devices, each capable of executing services including execution of predetermined processing and capable of accessing each other for the services, and a plurality of edge access permission devices, each determining whether or not to allow the access based on a predetermined access policy, the information processing device including: an acquisition unit that acquires a policy verification result including a determination result of whether or not to allow the access from each of the plurality of edge access permission devices; and an output unit that outputs verification information regarding a master policy verification result including a final determination result of whether or not to allow the access, based on the policy verification result from each of the plurality of edge access permission devices.

20. A program for causing a computer to execute the information processing method according to any one of claims 1 to 4.

Images