Access permission device, access permission method, and program

Abstract

An access permission device according to one aspect of the present disclosure is provided in a control network system configured from a plurality of electronic control devices. The electronic control devices execute a service including one of transferring data and executing a prescribed process. The electronic control devices access each other's services via the control network system. The control network system is furthermore provided with a plurality of edge access permission devices. The edge access permission devices are each provided with a policy determination unit that, on the basis of a prescribed access policy, outputs a policy verification result that is the result of determining accessibility. The policy determination unit transmits the policy verification result to the access permission device. The access permission device is provided with a master policy determination unit (106) that, on the basis of the policy verification results transmitted from the plurality of edge access permission devices, outputs a master policy verification result that is the final result of determining accessibility.

Description

Access permission device, access permission method, and program

[0001] The present disclosure relates to an access permission device, an access permission method, 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 access permission device 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 access permission device according to one aspect of the present disclosure is an access permission device in a control network system composed of a plurality of electronic control devices, each of which executes a service including either the transmission and reception of data or the execution of a predetermined process, and is configured to be able to access each other's services via the control network system, and the control network system further includes a plurality of edge access permission devices, each of which transmits a policy verification result, which is a determination result of whether access is possible, to the access permission device based on a predetermined access policy, and the access permission device includes a master policy determination unit that outputs a master policy verification result, which is a final determination result of whether access is possible, based on the policy verification result transmitted from each of the plurality of edge access permission devices.

[0008] An access permission method according to one aspect of the present disclosure is an access permission method executed by an access permission device in a control network system consisting of a plurality of electronic control devices, each of which executes a service including either the transmission and reception of data or the execution of a predetermined process, and is configured to be able to access each other's services via the control network system, and the control network system further includes a plurality of edge access permission devices, each of which transmits a policy verification result, which is a determination result of whether access is allowed or not, to the access permission device based on a predetermined access policy, and the access permission method outputs a master policy verification result, which is a final determination result of whether access is allowed or not, based on the policy verification result transmitted 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 the access permission method according to one aspect of the present disclosure.

[0010] According to an access permission device 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 an object in 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 modification. FIG. 15 is a block diagram illustrating a functional configuration of a central ECU according to the first modification. Fig. 16 is a block diagram showing the functional configuration of a zone ECU according to Modification 1. Fig. 17 is a diagram showing an example of a vehicle state according to Modification 1. 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 Modification 1. Fig. 19 is a diagram showing an example of a visualized state when there is a zone ECU whose policy verification result according to the embodiment is different from the others.

[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] (Embodiment) [Configuration] First, the configuration of an in-vehicle network system according to an embodiment will be described.

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

[0016] The in-vehicle network system includes a central ECU 100, zone ECUs 200a, 200b, 200c, and 200d, a camera ECU 300a, a charger ECU 300b, a brake ECU 300c, and a motor ECU 300d.

[0017] 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.

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

[0019] 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.

[0020] 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) 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 access permission device.

[0021] 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.

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

[0023] The charger ECU 300 b controls charging of the battery mounted on the vehicle 10 .

[0024] The brake ECU 300 c controls the brakes of the vehicle 10 .

[0025] The motor ECU 300d controls the motor of the vehicle.

[0026] When communicating with other ECUs, each ECU transmits and receives various data, control instructions, etc., using, for example, the 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.

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

[0028] 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 holding unit 108, a vehicle state holding unit 109, and a user information holding unit 110.

[0029] The center communication unit 101 is a communication interface that communicates with a server outside the vehicle 10 .

[0030] 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.

[0031] 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.

[0032] 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.

[0033] 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 communication.

[0034] 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.

[0035] 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 verification results of the access policies notified by policy determination units 202 arranged 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.

[0036] 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.

[0037] The access policy holding unit 108 is a storage that stores information about policies for controlling access to vehicle functions, the details of which will be described later with reference to FIG.

[0038] The vehicle state storage unit 109 is a storage that stores information on the current vehicle state, and will be described in detail later with reference to FIG.

[0039] The user information storage unit 110 is a storage unit that stores user information, and will be described in detail later with reference to FIG.

[0040] 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.

[0041] 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 .

[0042] The in-vehicle network communication unit 201 is a communication interface for the in-vehicle network, and communicates with the central ECU 100 or 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.

[0043] 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.

[0044] 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.

[0045] The policy enforcement unit 203 has the same function as the policy enforcement unit 107, and permits or denies access to vehicle functions based on the notification of access permission or denial notified from the policy determination unit 202 or the master policy determination unit 106. Specifically, the policy enforcement unit 203 controls the transfer or discarding of messages acquired by the in-vehicle network communication unit 201.

[0046] The access policy holding unit 204 is a storage that stores information about 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 included in the central ECU 100, and details will be described later using FIG. 5 .

[0047] The vehicle state storage unit 205 is a storage that stores information on 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 .

[0048] 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.

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

[0050] 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.

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

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

[0053] 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.

[0054] The access policy is information indicating the destination IP address and 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.

[0055] 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.

[0056] The communication of the in-vehicle network may be realized by, for example, Scalable Service Oriented Middleware over IP (SOME / IP), and the service ID corresponds to the Message ID or Service ID in SOME / IP.

[0057] The key characteristics are classified as availability, security, and confidentiality.

[0058] Availability is assigned to services for which service continuity is an important factor. For example, this applies to services such as camera information and vehicle status notifications, where the blocking of information can affect vehicle control. For services for which availability is important, real-timeness or service continuity is required, so the master policy determination unit 106 or the policy determination unit 202 carefully determines whether to block communication for the service. In other words, rather than a single policy determination unit 202 determining whether to deny access, the master policy determination unit 106 determines whether to deny access based on the results of multiple policy determination units 202. Furthermore, because real-timeness is required, the master policy determination unit 106 performs access control to allow communication until it determines that access is denied.

[0059] Safety is assigned to services that may have a direct impact on vehicle control. For example, this applies to services that receive brake or motor control instructions and control the brake or motor. Services for which safety is important must be able to immediately block access to unauthorized services, and real-time performance is also required because they involve vehicle control. Therefore, whether to permit or deny access to a service is determined based on the decision of a single policy decision unit 202.

[0060] Confidentiality is assigned to services that do not want information contained in the service to be read by applications other than authorized applications. For example, this applies to services that provide information related to a user's personal information. For services where confidentiality is important, real-time performance is not required, but access permission must be carefully determined. Therefore, the master policy determination unit 106 or the policy determination unit 202 determines whether to permit access to the communication for that service based on the results of multiple policy determination units 202. Furthermore, access control is performed so that communication is suspended until access permission is determined.

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

[0062] In addition, it is not necessary to set values ​​for both the destination IP address and the source IP address, and only one of the IP addresses may be set. Also, multiple IP addresses may be set.

[0063] 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.

[0064] The service ID may be anything that represents an identifier of the service, and may be included in the message or may be a port number.

[0065] Furthermore, there may be services for which no important characteristics are set. For services for which no important characteristics are set, access is permitted / denied according to a standard set by default (for example, a determination by a single policy determination unit 202).

[0066] The access policy may be stored in an encrypted form.

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

[0068] The access policy may also be updated according to a regular procedure, which may include, for example, 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 before updating the access policy.

[0069] 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.

[0070] The vehicle status stores the current vehicle status based on information notified via the in-vehicle network. Specifically, the vehicle status storage units 109 and 205 store the vehicle's driving status, the ON / OFF status of the autonomous driving mode, and the remaining battery power status as the vehicle status. Figure 6 shows the vehicle's driving status as being in driving, the autonomous driving mode as being OFF, and the remaining battery power as being 70%.

[0071] 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 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.

[0072] 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.

[0073] 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.

[0074] The user information storage unit 110 stores, as user information, specifically, the name, address, telephone number, and credit card information of the vehicle user.

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

[0076] 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.

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

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

[0079] 8 is a sequence diagram (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.

[0080] First, the central ECU 100 transmits a camera information service search message for requesting the 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.

[0081] When the zone ECUs 200a, 200b, 200c, and 200d receive a camera information service search message, they check whether the message conforms to an access policy (S101). That is, when the zone ECUs 200a, 200b, 200c, and 200d receive a camera information service search message, they determine the access policy of the search message.

[0082] Thereafter, the zone ECUs 200a, 200b, 200c, and 200d first transfer a camera information service search message to their respective zones because availability is an important characteristic of the camera information service (S102).

[0083] Furthermore, the zone ECUs 200a, 200b, 200c, and 200d respond (transmit) to the central ECU 100 that the verification result of the access policy is OK (S103).

[0084] Since the access 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).

[0085] 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 verification result of the access policy sent from the zone ECUs 200a, 200c, and 200d.

[0086] The zone ECU 200a transfers the SOME / IP-SD message (Offer message) received from the camera ECU 300a of its own zone to the central ECU 100 (S105).

[0087] The central ECU 100 transmits a message requesting the use of the camera information service to the zone ECU 200a based on the Offer message received from the camera ECU 300a (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.

[0088] 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.

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

[0090] First, the zone ECU 200b receives the camera information service search message 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).

[0091] The central ECU 100 and the zone ECUs 200a, 200c, and 200d to which the camera information service search message has been transferred check the access policy regarding the message (received message) (S201).

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

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

[0094] 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).

[0095] 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).

[0096] 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).

[0097] The central ECU 100 comprehensively determines the verification results of the access policies received from the zone ECUs 200a, 200c, and 200d, and notifies the corresponding zone ECUs, the zone ECUs 200a and 200b, of a message prohibiting the charger ECU 300b that 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 block the camera information service.

[0098] In step S207, the master policy determination unit 106 of the central ECU 100 outputs a master policy verification result, which is the final judgment result on whether 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 (in this case, a blocking request, since access was determined to be denied).

[0099] 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.

[0100] FIG. 10 is a flowchart (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.

[0101] First, the central ECU 100 receives a SOME / IP-SD message (a service Find message or a service Offer message) from the in-vehicle network (S300).

[0102] The central ECU 100 checks the provided or requested service ID contained in the received SOME / IP-SD message and determines whether the important characteristics of the service related to the received message are secure by referring to the access policy holding unit 108 (S301).

[0103] 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.

[0104] 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 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.

[0105] 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).

[0106] 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.

[0107] 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.

[0108] 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).

[0109] 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).

[0110] 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 three (S307).

[0111] 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).

[0112] 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.

[0113] 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 permits the transfer of the message (S309).

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

[0115] 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 two (S311).

[0116] If it is determined that the number of received policy verification results OK from zone ECUs 200a, 200b, 200c, and 200d is less than two (Yes in S311), central ECU 100 notifies zone ECUs 200a, 200b, 200c, and 200d to prohibit communication that violates the access policy for the service (S312), and then terminates the processing.

[0117] 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.

[0118] 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.

[0119] 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 central ECU 100.

[0120] 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, but may also be a SOME / IP message or a Data Distribution Service (DDS) message.

[0121] 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.

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

[0123] 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).

[0124] The zone ECU 200a checks the provided or requested service ID contained in the received SOME / IP-SD message and determines whether the important characteristics of the service related to the received message are secure by referring to the access policy holding unit 204 (S401).

[0125] 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.

[0126] Furthermore, for a SOME / IP-SD message that includes 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 that includes service IDs whose important characteristics are different, safety and availability, the zone ECU 200a may create a SOME / IP-SD message that includes only the 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.

[0127] 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).

[0128] If it is determined that the next received message matches the access policy (Yes in S402), the zone ECU 200a permits the transfer of the message (S403) and ends the process.

[0129] 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.

[0130] 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).

[0131] 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).

[0132] Furthermore, the zone ECU 200a receives the final decision result of whether access is permitted or denied from the central ECU 100, and determines whether the decision result is access denial (NG) (S407).

[0133] 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).

[0134] 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.

[0135] 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 permits the transfer of the message (S409).

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

[0137] Thereafter, the zone ECU 200a receives the final determination result of whether access is permitted or denied from the central ECU 100 and determines whether the result is either of the two. For example, the zone ECU 200a determines whether the final determination result of whether access is permitted or denied is access denied (NG) (S411).

[0138] 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.

[0139] On the other hand, if the zone ECU 200a determines that the access is permitted as the final determination result (No in S411), it ends the process without doing anything.

[0140] 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.

[0141] 12 is a flowchart (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. Note that the policy determination units 202 of the zone ECUs 200a, 200b, 200c, and 200d also perform similar processes.

[0142] 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).

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

[0144] 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 (S502) and terminates the processing.

[0145] 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).

[0146] If it is determined that the vehicle's running condition has changed while the vehicle is running (Yes in S503), the central ECU 100 changes the important characteristic of the communication for the service related to brake control to safety (S504) and ends the processing.

[0147] 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.

[0148] 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 (S506) and terminates the processing.

[0149] 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.

[0150] 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.

[0151] FIG. 13 is a flowchart (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 is different from the other zone ECUs.

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

[0153] If there is a zone ECU that returns a different verification result (Yes in S600), the central ECU 100 requests the zone ECU that returned the different verification result for the version of the access policy (S601).

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

[0155] Next, when the central ECU 100 receives the version of the access policy from the zone ECU that returned a different 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 that the central ECU 100 itself holds (S602).

[0156] In addition, instead of comparing the version of the access policy with the version information of the access policy that the central ECU 100 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.

[0157] 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 that expected, updates the access policy of the zone ECU (S603), and terminates the processing.

[0158] 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 the verification results from the corresponding zone ECU from the next time onwards (S604), and ends the processing. Ignoring may mean not performing any processing on the verification results even if they are received from the corresponding zone ECU.

[0159] 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.

[0160] 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.

[0161] [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.

[0162] [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.

[0163] 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.

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

[0165] 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.

[0166] 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.

[0167] The integrity verification unit 206 verifies that the functional configuration of the zone ECU 2000a has not been tampered with. Specifically, it 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 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.

[0168] 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.

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

[0170] 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.

[0171] 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.

[0172] 17 stores the integrity verification results and the in-vehicle network intrusion detection results notified from the zone ECUs 2000a, 2000b, 2000c, and 2000d in addition to the information stored in the vehicle state shown in FIG. 6. The in-vehicle network intrusion detection results are the detection results of the in-vehicle network intrusion detection system.

[0173] 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.

[0174] 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.

[0175] 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.

[0176] The timing for determining the threshold may be calculated each time the threshold is referenced (i.e., this process is executed immediately before step S307 or step S311), or a process for determining the threshold may be executed in advance.

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

[0178] If it is determined that confidentiality is an 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 of the number of receptions for which the policy verification result is OK received from the zone ECUs 2000a, 2000b, 2000c, and 2000d to "the number of zone ECUs placed in the in-vehicle network system - 1", or in this modified example, 4 - 1 = 3 (S701).

[0179] 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 of the number of receptions for which the policy verification result is OK received from the zone ECUs 2000a, 2000b, 2000c, and 2000d to "the number of zone ECUs placed in the in-vehicle network system - 2", or in this modified example, 4 - 2 = 2 (S702).

[0180] 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 a zone ECU whose integrity verification has passed within the last five minutes (S703).

[0181] 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 the weight of the policy verification result (access OK / NG) received from the corresponding zone ECU to 2 (for example, from 1 to 2) (S704). The weight of one zone ECU under normal circumstances is set to 1, and the weight of the zone ECU that received the policy verification result of OK is set to 2, and it is considered to be the same as if two policy verification results of OK had been received.

[0182] 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.

[0183] 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).

[0184] If it is determined that there is a zone ECU that has detected an abnormality in the in-vehicle network intrusion detection system (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 terminates the processing.

[0185] 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.

[0186] 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.

[0187] 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.

[0188] [Variation 2] Figure 19 shows an example of an analysis screen displayed 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. Figure 19 shows the IP address information of the ECU that made the service request when the policy verification result was inconsistent, and the result of the service that was attempted to be accessed. Furthermore, a screen is displayed that lists the verification results, software versions (SW versions), and policy versions for the central ECU 100 and each of the zone ECUs 200a, 200b, 200c, and 200d. In Figure 19, although all ECUs use the same policy version, only zone ECU 200b returns a verification result of "NG," indicating an inconsistency in the policy verification results.

[0189] [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.

[0190] (Technology 1) An access permission device in a control network system made up of a plurality of electronic control devices, each of which executes a service including either sending and receiving data or executing a predetermined process, and which is configured to be able to access each other's services via the control network system, and the control network system further comprises a plurality of edge access permission devices, each of which transmits a policy verification result, which is a determination result of whether access is possible, to the access permission device based on a predetermined access policy, and the access permission device comprises a master policy determination unit which outputs a master policy verification result, which is a final determination result of whether access is possible, based on the policy verification results transmitted from each of the plurality of edge access permission devices.

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

[0192] Conventionally, this type of access authorization device determines whether 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 authorization device according to one aspect of the present disclosure verifies distributed access policies at multiple verification points to make a final access authorization decision. This allows for a highly reliable access authorization decision, thereby maintaining the security of the control network system. In other words, when the access authorization 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.

[0193] (Technology 2) An access permission device according to Technology 1, wherein the access policy holds information about either one or both of electronic control devices among the multiple electronic control devices that are permitted to access the service and electronic control devices among the multiple electronic control devices that are permitted to provide the service, and each of the multiple edge access permission devices receives a message indicating provision and receipt of the service from one of the multiple electronic control devices, and transmits a policy verification result determining whether or not the one electronic control device can access the service for the received message indicating provision and receipt of the service to the access permission device, and is configured to be able to discard the message indicating provision and receipt of the service if the access is denied, and the master policy determination unit transmits a master policy verification result indicating access denial to each of the multiple edge access permission devices if it receives policy verification results indicating access denial equal to or greater than a predetermined access denial threshold. Note that the access denial threshold is a threshold for the number of times that a policy verification result indicating access denial is received.

[0194] The service can be accessed by an ECU via, for example, SOME / IP communication. When an ECU sends a message requesting an unauthorized service, the access policy is verified by multiple zone ECUs. If the verification result is equal to or exceeds a threshold value that results in access denial, the message is discarded and access to the service is denied.

[0195] 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.

[0196] (Technology 3) A service is classified as a service requiring availability if the content of the service is the exchange of sensor data, and the master policy determination unit is an access permission device described in Technology 2, which increases the value of the access denial threshold for services requiring availability.

[0197] 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.

[0198] (Technology 4) A service is classified as a service requiring confidentiality if the content of the service involves the exchange of data related to personal information or confidential information, and the master policy determination unit is an access permission device described in Technology 2 or 3 that reduces the access denial threshold value for services requiring confidentiality.

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

[0200] (Technology 5) An access authorization device according to any one of Technologies 2 to 4, in which a service is classified as a service requiring safety if the content of the service relates to control of an actuator that requires real-time performance, and the master policy determination unit allows multiple edge access authorization devices to determine whether or not to allow access to the service based on the policy verification results of the multiple edge access authorization devices, without waiting for the output of the master policy verification result, for a service requiring safety.

[0201] 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.

[0202] (Technology 6) The control network system is an in-vehicle network system mounted on a vehicle, and the master policy determination unit is an access authorization device described in any one of Technologies 2 to 5, which holds a vehicle state including one or more of the vehicle's driving state, charging state, update state, diagnostic mode state, and autonomous driving mode, and increases or decreases the numerical value of the access denial threshold depending on the vehicle state and the service.

[0203] 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.

[0204] (Technology 7) An access authorization device according to any one of Technologies 2 to 6, wherein at least one of the multiple edge access authorization devices is configured to be able to transmit an integrity verification result, which verifies that its own software or data has not been tampered with, to an access authorization device, and the master policy determination unit increases or decreases the weight of the policy verification result received from at least one edge access authorization device based on the integrity verification result received from at least one edge access authorization device.

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

[0206] (Technology 8) The master policy determination unit is an access authorization device according to any one of Technologies 2 to 7, which, if there is an edge access permission device among a plurality of edge access permission devices that transmits a policy verification result that differs from the other edge access permission devices, requests the edge access permission device to transmit information about the access policy it holds.

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

[0208] (Technology 9) An access permission method executed by an access permission device in a control network system composed of multiple electronic control devices, each of which executes a service including either sending and receiving data or executing a predetermined process, and which is configured to be able to access each other's services via the control network system, and the control network system further includes multiple edge access permission devices, each of which transmits a policy verification result, which is a determination result of whether access is permitted or not, to the access permission device based on a predetermined access policy, and the access permission method is an access authorization method that outputs a master policy verification result, which is a final determination result of whether access is permitted or not, based on the policy verification results transmitted from each of the multiple edge access permission devices.

[0209] According to such an access authorization method, the same effects as those of the access authorization device according to one aspect of the present disclosure can be achieved.

[0210] (Technology 10) A program for causing a computer to execute the access permission method described in Technology 9.

[0211] Such a program provides the same effects as the access authorization device according to one aspect of the present disclosure.

[0212] 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.

[0213] 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.

[0214] For example, the in-vehicle communication network system may include not only an in-vehicle network system but also other mobility network systems and / or control network systems. Furthermore, the communication standards for communications performed in such systems are not particularly limited. Furthermore, the architecture of the in-vehicle communication network system is not limited to the example shown in FIG. 1 .

[0215] 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.

[0216] 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.

[0217] 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) that are managed by the ECU and control equipment mounted on the object, the access permission device including: 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 ultimately permitted for the access request based on the policy verification result acquired from each of the one or more zone ECUs.

[0218] 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) 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.

[0219] 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.

[0220] 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.

[0221] 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.

[0222] 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.

[0223] 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.

[0224] 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.

[0225] 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.

[0226] 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.

[0227] 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.

[0228] 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.

[0229] 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.

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

[0231] 10, 20 Vehicle 100, 1000 Central ECU (access permission device) 101 Center communication unit 102 Vehicle control application unit 103 Driver application unit 104 Autonomous driving application unit 105, 201 In-vehicle network communication 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 access permission device in a control network system composed of a plurality of electronic control devices, each of which executes a service including either data transmission and reception or execution of a specified process, and which is configured to be able to access each other's services via the control network system, the control network system further comprising a plurality of edge access permission devices, each of which transmits a policy verification result, which is a judgment result on whether access is allowed or not, to the access permission device based on a specified access policy, the access permission device comprising a master policy judgment unit which outputs a master policy verification result, which is a final judgment result on whether access is allowed or not, based on the policy verification result transmitted from each of the plurality of edge access permission devices.

2. The access policy holds information regarding either or both of electronic control devices among the multiple electronic control devices that are permitted to access the service and electronic control devices among the multiple electronic control devices that are permitted to provide the service, and each of the multiple edge access permission devices is configured to receive a message indicating provision of a service by one of the multiple electronic control devices, transmit the policy verification result determining whether the one electronic control device can access the service in response to the received message indicating provision of the service to the access permission device, and be capable of discarding the message indicating provision of the service when the master policy verification result is access denial, and when the master policy judgment unit receives a policy verification result indicating access denial equal to or greater than a predetermined access denial threshold, transmits the master policy verification result indicating access denial to each of the multiple edge access permission devices.

3. The access permission device of claim 2, wherein the service is classified as a service requiring availability when the content of the service is the transmission and reception of sensor data, and the master policy decision unit increases the value of the access denial threshold for services requiring availability.

4. The access permission device of claim 2 or 3, wherein the service is classified as a service requiring confidentiality if the content of the service is the exchange of data related to personal information or confidential information, and the master policy decision unit reduces the value of the access denial threshold for services requiring confidentiality.

5. An access permission device as described in any one of claims 2 to 4, wherein the service is classified as a service requiring safety when the content of the service relates to the control of an actuator requiring real-time performance, and the master policy judgment unit allows the multiple edge access permission devices to determine whether or not to allow access to the service based on the policy verification results of the multiple edge access permission devices, for a service requiring safety, without waiting for the output of the master policy verification result.

6. The access permission device according to any one of claims 2 to 5, wherein the control network system is an in-vehicle network system mounted in a vehicle, and the master policy determination unit retains a vehicle state including one or more of the vehicle's driving state, charging state, update state, diagnostic mode state, and autonomous driving mode, and increases or decreases the numerical value of the access denial threshold depending on the vehicle state and the service.

7. An access permission device as described in any one of claims 2 to 6, wherein at least one of the multiple edge access permission devices is configured to be able to transmit an integrity verification result verifying that its own software or data has not been tampered with to the access permission device, and the master policy judgment unit increases or decreases the weight of the policy verification result received from the at least one edge access permission device based on the integrity verification result received from the at least one edge access permission device.

8. The access permission device according to any one of claims 2 to 7, wherein, when there is an edge access permission device among the plurality of edge access permission devices that transmits a policy verification result different from that of the other edge access permission devices, the master policy decision unit requests the edge access permission device to transmit information about the access policy it holds.

9. An access permission method executed by an access permission device in a control network system composed of a plurality of electronic control devices, each of which executes a service including either data transmission and reception or execution of a specified process, and is configured to be able to access each other's services via the control network system, the control network system further comprising a plurality of edge access permission devices, each of which transmits a policy verification result, which is a judgment result on whether access is allowed or not, to the access permission device based on a specified access policy, the access permission method outputting a master policy verification result, which is a final judgment result on whether access is allowed or not, based on the policy verification result transmitted from each of the plurality of edge access permission devices.

10. A program for causing a computer to execute the access permission method according to claim 9.

Images