In-vehicle system, security management method, and security management program

Abstract

To realize an excellent function in regard to a security in an on-vehicle network.SOLUTION: An on-vehicle system mounted onto a vehicle, comprises: a plurality of function parts that contains a first function part and a second function part that include a different construction in regard to a security each other; and a control part that performs an alternative processing for alternating a reception of an access to the second function part by stopping the access from an external device to the first function part in the case where a state of the first function part and a state of the second function part are in a normal state, and a risk notification in regard to a security risk of the first function part is received from the external device in an external part of the vehicle.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present disclosure relates to an in-vehicle system, a security management method, and a security management program. [Background technology]

[0002] Conventionally, technologies for improving security in in-vehicle networks have been developed. For example, Patent Document 1 (JP 2020-501420 A) discloses the following technology. That is, a method for an in-vehicle network is a method for an in-vehicle network in which data is transferred via at least one communication path (60) for communication within the in-vehicle network, the method comprising a step of evaluating (86) the communication path (60) that may transfer data with respect to an attack risk, wherein the attack risk is a risk that the communication path (60) is attacked because the communication path (60) exploits a security gap. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Special Publication No. 2020-501420 [Patent Document 2] Japanese Patent Application Laid-Open No. 2009-71436 Summary of the Invention [Problem to be solved by the invention]

[0004] There is a demand for a technology that goes beyond the technology described in Patent Document 1 and that can achieve excellent security functions in an in-vehicle network.

[0005] The present disclosure has been made to solve the above-mentioned problems, and its purpose is to provide an in-vehicle system, a security management method, and a security management program that can realize excellent security functions in an in-vehicle network. [Means for solving the problem]

[0006] The in-vehicle system of the present disclosure is an in-vehicle system mounted on a vehicle, and comprises a plurality of functional units including a first functional unit and a second functional unit having different security configurations, and a control unit that, when the state of the first functional unit and the state of the second functional unit are normal and a risk notification regarding a security risk of the first functional unit is received from an external device outside the vehicle, stops access to the first functional unit from the external device and performs alternative processing to have the second functional unit accept the access instead.

[0007] One aspect of the present disclosure can be realized not only as an in-vehicle system including such a characteristic processing unit, but also as a semiconductor integrated circuit that realizes part or all of the in-vehicle system. [Effects of the Invention]

[0008] According to the present disclosure, it is possible to realize excellent security functions in an in-vehicle network. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram illustrating a configuration of a communication system according to a first embodiment of the present disclosure. [Figure 2] FIG. 2 is a diagram showing a configuration of an in-vehicle system according to the first embodiment of the present disclosure. [Figure 3] FIG. 3 is a diagram illustrating a configuration of an in-vehicle relay device according to the first embodiment of the present disclosure. [Figure 4] FIG. 4 is a diagram illustrating an example of a routing table stored by the vehicle-mounted relay device according to the first embodiment of the present disclosure. [Figure 5] FIG. 5 is a functional block diagram showing a configuration of an in-vehicle system according to the first embodiment of the present disclosure. [Figure 6]FIG. 6 is a diagram illustrating a configuration of first software used by a first core of the vehicle-mounted relay device according to the first embodiment of the present disclosure. [Figure 7] FIG. 7 is a diagram illustrating a configuration of second software used by the second core of the vehicle-mounted relay device according to the first embodiment of the present disclosure. [Figure 8] FIG. 8 is a diagram illustrating an example of a routing table after the table update process by the vehicle-mounted relay device according to the first embodiment of the present disclosure. [Figure 9] FIG. 9 is a diagram illustrating an example of a management list created by a list creation process performed by the vehicle-mounted relay device according to the first embodiment of the present disclosure. [Figure 10] FIG. 10 is a flowchart defining an operation procedure when the core in the vehicle-mounted relay device according to the first embodiment of the present disclosure performs notification processing. [Figure 11] FIG. 11 is a flowchart defining an operation procedure when the relay unit in the vehicle-mounted relay device according to the first embodiment of the present disclosure performs the table update process and the list creation process. [Figure 12] FIG. 12 is a diagram illustrating an example of a sequence of processes performed by the in-vehicle relay device, the in-vehicle ECU, and the server in the communication system according to the first embodiment of the present disclosure. [Figure 13] FIG. 13 is a diagram illustrating an example of a sequence of processes performed by the in-vehicle relay device, the in-vehicle ECU, and the server in the modified example of the communication system according to the first embodiment of the present disclosure. [Figure 14] FIG. 14 is a diagram illustrating an example of a routing table stored by the vehicle-mounted relay device according to the second embodiment of the present disclosure. [Figure 15] FIG. 15 is a diagram illustrating a configuration of first software used by a first functional unit according to the second embodiment of the present disclosure. [Figure 16] FIG. 16 is a diagram illustrating a configuration of second software used by a second functional unit according to the second embodiment of the present disclosure. [Figure 17]FIG. 17 is a diagram illustrating an example of a routing table after the table update process by the vehicle-mounted relay device according to the second embodiment of the present disclosure. [Figure 18] FIG. 18 is a diagram illustrating an example of a management list created by a list creation process performed by an in-vehicle relay device according to the second embodiment of the present disclosure. [Figure 19] FIG. 19 is a diagram illustrating an example of a sequence of processes performed by the in-vehicle relay device, the in-vehicle ECU, and the server in the communication system according to the second embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0010] First, the contents of the embodiments of the present disclosure will be listed and described. (1) An in-vehicle system according to an embodiment of the present disclosure is an in-vehicle system mounted on a vehicle, and includes a plurality of functional units including a first functional unit and a second functional unit having different security configurations, and a control unit that, when the state of the first functional unit and the state of the second functional unit are normal and a risk notification regarding a security risk of the first functional unit is received from an external device outside the vehicle, stops access to the first functional unit from the external device and performs alternative processing to have the second functional unit accept the access instead.

[0011] In this way, by providing multiple access routes from outside the vehicle that have little correlation with respect to security risks, if a security risk is discovered in one access route, it is possible to switch to another access route in which no security risk has been discovered, thereby ensuring the security of the in-vehicle network while transmitting and receiving information to and from devices outside the vehicle. Furthermore, by configuring the access route from outside the vehicle to be switched in advance when each functional unit is normal, it is possible to prevent a functional unit in which a security risk has been discovered from being attacked from outside the vehicle, thereby further improving security. Therefore, excellent security functions can be realized in the in-vehicle network.

[0012] (2) In the above (1), after receiving the risk notification from the external device, the control unit may further perform a communication continuation process to continue communication within the vehicle by the first functional unit.

[0013] With this configuration, even if a security risk regarding the first functional unit is notified, it is possible to continue providing various services by the first functional unit in the in-vehicle network.

[0014] (3) In (2) above, the control unit may, as the communication continuation process, continue communication between the first functional unit and other functional units among the plurality of functional units other than the first functional unit and the second functional unit.

[0015] With this configuration, even if a security risk is discovered regarding the first functional unit, services can be continuously provided in the in-vehicle network using communication between the first functional unit and functional units other than the first functional unit and the second functional unit.

[0016] (4) In the above (2) or (3), the control unit may continue the communication between the first function unit and the second function unit as the communication continuation process.

[0017] With this configuration, for example, even if information addressed to a first functional unit that has been notified of a security risk is received from a device outside the vehicle, the information can be transferred from a second functional unit that has not been notified of a security risk to the first functional unit, so that processing using information from the device outside the vehicle can continue to be executed in the first functional unit.

[0018] (5) In any of the above (1) to (4), the configuration may be such that the first software used by the first functional unit and the second software used by the second functional unit are different.

[0019] In this way, by configuring the software in which security risks are more likely to be discovered to be different between multiple functional units, even if a security risk is notified about the software in the first functional unit, it is possible to continue to execute specified services in the in-vehicle network using the software in the second functional unit, which has better security.

[0020] (6) In (5) above, the function provided by the first software may include a function to perform secure communication according to a first communication protocol, and the function provided by the second software may include a function to perform the secure communication according to a second communication protocol different from the first communication protocol.

[0021] In this way, by configuring the communication protocols for secure communication, which is likely to result in the discovery of security risks and have a significant impact on in-vehicle equipment, to be different among multiple functional units, even if a security risk is notified about the communication protocol in the first functional unit, secure communication can be performed using the communication protocol in the second functional unit, which has better security.

[0022] (7) In the above (5) or (6), the first software may include a first application, and the second software may include a second application different from the first application.

[0023] In this way, by configuring applications that are likely to have a high probability of security risks being discovered and that are likely to have a large impact on services used by users in the vehicle to be different between multiple functional units, even if a security risk is notified about an application in a first functional unit, it is possible to provide a specified function using an application in a second functional unit that has better security.

[0024] (8) In any of (5) to (7) above, the first software may include a first OS (Operating System), and the second software may include a second OS different from the first OS.

[0025] In this way, by configuring the OS, which is the part of the software where security risks are likely to be discovered and which is likely to have the greatest impact, to be different between multiple functional units, even if a security risk is notified about the OS in the first functional unit, it is possible to provide the specified function using the OS in the second functional unit, which has better security.

[0026] (9) A security management method according to an embodiment of the present disclosure is a security management method for an in-vehicle system mounted on a vehicle, the in-vehicle system having a plurality of functional units including a first functional unit and a second functional unit having different security configurations, the method including, when the state of the first functional unit and the state of the second functional unit are normal, receiving a risk notification regarding a security risk of the first functional unit from an external device outside the vehicle, and, when the risk notification is received, performing an alternative process of stopping access from the external device to the first functional unit and having the second functional unit accept the access instead.

[0027] In this way, by providing multiple access routes from outside the vehicle that have little correlation with respect to security risks, if a security risk is discovered in one access route, it is possible to switch to another access route in which no security risk has been discovered, thereby ensuring the security of the in-vehicle network while transmitting and receiving information to and from devices outside the vehicle. Furthermore, by configuring the access route from outside the vehicle to be switched in advance when each functional unit is normal, it is possible to prevent a functional unit in which a security risk has been discovered from being attacked from outside the vehicle, thereby further improving security. Therefore, excellent security functions can be realized in the in-vehicle network.

[0028] (10) A security management program according to an embodiment of the present disclosure is a security management program used in an in-vehicle system mounted on a vehicle, the in-vehicle system having multiple functional units, including a first functional unit and a second functional unit, each having a different security configuration, and is a program for causing a computer to function as a control unit that, when the state of the first functional unit and the state of the second functional unit are normal and a risk notification regarding a security risk of the first functional unit is received from an external device outside the vehicle, stops access to the first functional unit from the external device and performs alternative processing to have the second functional unit accept the access instead.

[0029] In this way, by providing multiple access routes from outside the vehicle that have little correlation with respect to security risks, if a security risk is discovered in one access route, it is possible to switch to another access route in which no security risk has been discovered, thereby ensuring the security of the in-vehicle network while transmitting and receiving information to and from devices outside the vehicle. Furthermore, by configuring the access route from outside the vehicle to be switched in advance when each functional unit is normal, it is possible to prevent a functional unit in which a security risk has been discovered from being attacked from outside the vehicle, thereby further improving security. Therefore, excellent security functions can be realized in the in-vehicle network.

[0030] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In the drawings, identical or corresponding parts are designated by the same reference numerals, and their description will not be repeated. Furthermore, at least some of the embodiments described below may be combined in any manner.

[0031] First Embodiment [In-vehicle system] 1 is a diagram showing a configuration of a communication system according to a first embodiment of the present disclosure. Referring to FIG. 1, a communication system 501 includes a server 180 and one or more in-vehicle systems 301. The in-vehicle systems 301 are mounted on a vehicle 1. The server 180 is an example of an external device outside the vehicle 1.

[0032] 2 is a diagram illustrating a configuration of an in-vehicle system according to the first embodiment of the present disclosure. Referring to FIG. 2, an in-vehicle system 301 includes, for example, one in-vehicle relay device 101 and a plurality of in-vehicle ECUs (Electronic Control Units) 202.

[0033] 2, the in-vehicle system 301 includes in-vehicle ECUs 202A, 202B, and 202C that are the in-vehicle ECUs 202. The in-vehicle relay device 101 and the in-vehicle ECUs 202 configure an in-vehicle network 401.

[0034] The in-vehicle system 301 is not limited to a configuration including three in-vehicle ECUs 202, but may be a configuration including one, two, or four or more in-vehicle ECUs 202. The in-vehicle system 301 is not limited to a configuration including one in-vehicle relay device 101, but may be a configuration including multiple in-vehicle relay devices 101.

[0035] The in-vehicle relay device 101 is, for example, a gateway device, and can relay data between a plurality of in-vehicle ECUs 202 connected thereto.

[0036] The in-vehicle relay device 101 and each in-vehicle ECU 202 generate various information such as information to assist the automatic driving performed by the vehicle 1 and information used for entertainment, and transmit it to other in-vehicle ECUs 202 or in-vehicle relay devices 101.

[0037] The in-vehicle ECU 202 is a TCU (Telematics Communication Unit), an engine ECU, an automatic driving ECU, a door lock ECU, etc. In addition to the in-vehicle ECU 202 or instead of the in-vehicle ECU 202, the in-vehicle system 301 may include in-vehicle devices such as a sensor, a navigation device, a human-machine interface, and a camera.

[0038] The plurality of in-vehicle ECUs 202 are connected to an in-vehicle relay device 101 via, for example, an Ethernet (registered trademark) cable 10.

[0039] More specifically, the in-vehicle relay device 101 includes a plurality of communication ports 51. The communication ports 51 are terminals to which, for example, Ethernet cables 10 can be connected. The in-vehicle relay device 101 and each in-vehicle ECU 202 are connected to other in-vehicle ECUs 202 via the communication ports 51 and the Ethernet cables 10.

[0040] Here, the in-vehicle ECU 202C is a TCU, and will hereinafter also be referred to as a TCU 202C.

[0041] 1 and 2, the TCU 202C is capable of communicating with the server 180. The TCU 202C is capable of communicating with the server 180 via the wireless base station device 161, for example.

[0042] More specifically, the TCU 202C is capable of wirelessly communicating with the wireless base station device 161 in accordance with a communication standard such as LTE (Long Term Evolution) (registered trademark) or 5G.

[0043] Specifically, when wireless base station device 161 receives an IP packet from server 180 via external network 170, wireless base station device 161 transmits the received IP packet in a wireless signal to TCU 202C.

[0044] For example, when TCU202C receives a radio signal including an IP packet from server 180 from radio base station device 161, it acquires the IP packet from the received radio signal, stores the acquired IP packet in a frame, and transmits it to vehicle-mounted relay device 101.

[0045] Furthermore, when the TCU 202C receives a frame from the in-vehicle relay device 101, it acquires an IP packet from the received frame, and transmits the acquired IP packet to the wireless base station device 161 by including the IP packet in a wireless signal.

[0046] When the wireless base station device 161 receives the wireless signal from the TCU 202C, it acquires an IP packet from the received wireless signal and transmits the acquired IP packet to the server 180 via the external network 170.

[0047] The server 180 is provided outside the vehicle 1. The server 180 manages, for example, security risks of various software used in the in-vehicle network 401. Here, the security risks of the software include software vulnerabilities and threats to the software.

[0048] In addition, the vehicle relay device 101 is not limited to a configuration in which it is connected to the vehicle ECU 202 via an Ethernet cable 10, but may also be configured to be connected to the vehicle ECU 202 via a bus conforming to standards such as CAN (Controller Area Network), CAN FD (CAN with Flexible Data Rate), FlexRay (registered trademark), MOST (Media Oriented System Transport) (registered trademark), and LIN (Local Interconnect Network).

[0049] [In-vehicle relay device] FIG. 3 is a diagram illustrating a configuration of an in-vehicle relay device according to the first embodiment of the present disclosure. Referring to FIG. 3, the in-vehicle relay device 101 includes a communication port 51, a relay unit 52, and a processing unit 53. The processing unit 53 includes a plurality of cores 61 and a storage unit 62. One or both of the relay unit 52 and the processing unit 53 are realized by, for example, a processing circuit including one or more processors. Here, the core 61 corresponds to the processor. In the example illustrated in FIG. 3, the processing unit 53 includes cores 61A and 61B, which are cores 61.

[0050] The communication port 51 is, for example, a terminal to which an Ethernet cable 10 can be connected. In the example shown in Fig. 3, the in-vehicle relay device 101 includes communication ports 51A, 51B, and 51C, which are the communication ports 51. In-vehicle ECUs 202A, 202B, and 202C are connected to the communication ports 51A, 51B, and 51C via the Ethernet cable 10, respectively.

[0051] The in-vehicle relay device 101 is not limited to a configuration having three communication ports 51, but may be a configuration having one, two, or four or more communication ports 51.

[0052] Corresponding port numbers are assigned to the communication ports 51 and the cores 61. Here, the port numbers assigned to the communication ports 51A, 51B, and 51C are #1, #2, and #3, respectively, and the port numbers assigned to the cores 61A and 61B are #4 and #5, respectively.

[0053] When the relay unit 52 receives a frame from a certain in-vehicle ECU 202, the relay unit 52 transmits the received frame to the in-vehicle ECU 202 of the destination.

[0054] Furthermore, when the relay unit 52 receives a frame addressed to the core 61 in its own in-vehicle relay device 101 from the in-vehicle ECU 202, it outputs the frame to the core 61 of the destination.

[0055] Furthermore, the relay unit 52 transmits the frame received from the core 61 to the destination in-vehicle ECU 202 via the communication port 51 and the Ethernet cable 10 .

[0056] More specifically, the storage unit 62 stores a routing table Tb1 that indicates the correspondence between a source IP address, a destination IP address, and a port number included in a frame.

[0057] When the relay unit 52 receives a frame from the in-vehicle ECU 202 or the core 61, it reads out the routing table Tb1 in the storage unit 62. Then, by referring to the routing table Tb1, the relay unit 52 identifies the port numbers corresponding to the source IP address and destination IP address included in the frame.

[0058] FIG. 4 is a diagram illustrating an example of a routing table stored by the vehicle-mounted relay device according to the first embodiment of the present disclosure.

[0059] Referring to Figure 4, "IP_Server" indicates the IP address of server 180, "IP_Core A" indicates the IP address of core 61A, "IP_Core B" indicates the IP address of core 61B, "IP_ECU A" indicates the IP address of in-vehicle ECU 202A, "IP_ECU B" indicates the IP address of in-vehicle ECU 202B, and "IP_ECU C" indicates the IP address of in-vehicle ECU 202C.

[0060] When the relay unit 52 receives a frame including "IP_ECU A" and "IP_ECU B" as the source IP address and the destination IP address, respectively, the relay unit 52 specifies "#2" as the port number corresponding to the frame. When the relay unit 52 receives a frame including "IP_ECU B" and "IP_ECU A" as the source IP address and the destination IP address, respectively, the relay unit 52 specifies "#1" as the port number corresponding to the frame. When the relay unit 52 receives a frame including "IP_ECU C" and "IP_ECU A" as the source IP address and the destination IP address, respectively, the relay unit 52 specifies "#1" as the port number corresponding to the frame. When the relay unit 52 receives a frame including "IP_Server" and "IP_Core A" as the source IP address and the destination IP address, respectively, the relay unit 52 specifies "#4" as the port number corresponding to the frame. When the relay unit 52 receives a frame including "IP_Server" and "IP_Core B" as the source IP address and the destination IP address, respectively, the relay unit 52 specifies "#5" as the port number corresponding to the frame.

[0061] When the relay unit 52 receives a frame from the core 61A that includes "IP_Core A" and "IP_Server" as the source IP address and destination IP address, respectively, it identifies "#3" as the port number corresponding to the frame. When the relay unit 52 receives a frame from the core 61B that includes "IP_Core B" and "IP_Server" as the source IP address and destination IP address, respectively, it identifies "#3" as the port number corresponding to the frame.

[0062] When the relay unit 52 identifies the port number, it transmits the frame from the in-vehicle ECU 202 or the frame from the core 61 to the in-vehicle ECU 202 connected to the communication port 51 corresponding to the identified port number, or outputs it to the core 61 corresponding to the port number.

[0063] [Problem description] When a security risk is discovered in an in-vehicle system, it takes time to develop countermeasures to address the security risk, which increases the possibility that the in-vehicle system will be attacked.

[0064] As a temporary measure against security risks, it may be possible to stop providing the function in the in-vehicle system that corresponds to the part where the security risk was discovered. However, if the function is an important function in the in-vehicle system, it may not be possible to stop providing the function.

[0065] In contrast, the in-vehicle system according to the embodiment of the present disclosure solves the above problem with the following configuration and operation.

[0066] 5 is a functional block diagram showing the configuration of an in-vehicle system according to a first embodiment of the present disclosure. Referring to FIG. 5, an in-vehicle system 301 includes a first functional unit 11A, a second functional unit 11B, and a control unit 12. In the first embodiment of the present disclosure, the first functional unit 11A corresponds to the core 61A, and the second functional unit 11B corresponds to the core 61B. Note that the terms "first" and "second" do not imply a priority order.

[0067] 3, core 61A and core 61B have different configurations with respect to security. In other words, core 61A and core 61B have little relationship with respect to security risk. More specifically, for example, as a configuration difference with respect to security, software SW11 used by core 61A and software SW12 used by core 61B are different. Software SW11 is an example of first software, and software SW12 is an example of second software.

[0068] Fig. 6 is a diagram illustrating a configuration of first software used by a first core of the vehicle-mounted relay device according to the first embodiment of the present disclosure. Fig. 7 is a diagram illustrating a configuration of second software used by a second core of the vehicle-mounted relay device according to the first embodiment of the present disclosure.

[0069] 6 and 7, core 61A and core 61B are equipped with, for example, different OSs.

[0070] More specifically, for example, the software SW11 includes LINUX (registered trademark)_OS 21. LINUX_OS 21 is an example of a first OS. Note that the software SW11 may include a general-purpose OS other than LINUX_OS 21.

[0071] For example, software SW12 includes an OS different from LINUX_OS 21. Specifically, software SW12 includes an RTOS (Real Time Operating System) 22. RTOS 31 is an example of a second OS. Note that software SW12 may include an OS other than RTOS 31 as long as it is an OS different from the OS included in software SW1.

[0072] Furthermore, the core 61A and the core 61B are loaded with, for example, different applications.

[0073] More specifically, for example, the software SW11 includes an authentication application 22, and the software SW12 includes an authentication application 32 that is different from the authentication application 22. The authentication application 22 and the authentication application 32 are examples of a first application and a second application, respectively.

[0074] For example, the function provided by the authentication application 22 included in the software SW11 includes a TLS authentication function that performs secure communication in accordance with the TLS (Transport Layer Security) standard. TLS is an example of a first communication protocol.

[0075] Referring to Figures 1 and 3, specifically, when core 61A's own vehicle-mounted relay device 101 is started, for example, core 61A transmits authentication request information R11 indicating a request for authentication to server 180 via relay unit 52 and TCU 202C in a procedure conforming to TLS.

[0076] Specifically, for example, core 61A creates an IP packet that includes authentication request information R11 and includes its own IP address and the IP address of server 180 as the source IP address and destination IP address, respectively. Then, core 61A transmits the created IP packet to server 180 via relay unit 52 and TCU 202C.

[0077] For example, when the server 180 receives the authentication request information R11 from the in-vehicle relay device 101 via the TCU 202C, it performs authentication processing for the core 61A in accordance with a procedure conforming to TLS.

[0078] When the authentication of the core 61A is successful in the authentication process of the core 61A, the server 180 creates an IP packet including authentication success information R12 indicating successful authentication and including its own IP address and the IP address of the core 61A as the source IP address and destination IP address, respectively. Then, the server 180 transmits the created IP packet to the in-vehicle relay device 101 via the TCU 202C.

[0079] In the vehicle-mounted relay device 101, when the core 61A receives the IP packet including the authentication success information R12 from the server 180 via the TCU 202C and the relay unit 52, the core 61A starts communication with the server 180.

[0080] On the other hand, if the server 180 fails to authenticate the core 61A, the server 180 creates an IP packet that includes authentication failure information R13 indicating that the authentication has failed and that includes its own IP address and the IP address of the core 61A as the source IP address and destination IP address, respectively.The server 180 then transmits the created IP packet to the in-vehicle relay device 101 via the TCU 202C.

[0081] In the vehicle-mounted relay device 101, when the core 61A receives the IP packet including the authentication failure information R13 from the server 180 via the TCU 202C and the relay unit 52, it determines that communication with the server 180 is not possible.

[0082] For example, the function provided by the authentication application 32 included in the software SW12 includes an IPsec authentication function that performs secure communication in accordance with the IPsec (Security Architecture for Internet Protocol) standard. IPsec is an example of a second communication protocol.

[0083] More specifically, when the core 61B's own vehicle-mounted relay device 101 is started up, the core 61B transmits authentication request information R21 indicating a request for authentication to the server 180 via the relay unit 52 and the TCU 202C in accordance with a procedure conforming to IPsec.

[0084] Specifically, for example, core 61B creates an IP packet that includes authentication request information R21 and includes its own IP address and the IP address of server 180 as the source IP address and destination IP address, respectively. Then, core 61B transmits the created IP packet to server 180 via relay unit 52 and TCU 202C.

[0085] For example, when the server 180 receives the authentication request information R21 from the in-vehicle relay device 101 via the TCU 202C, it performs authentication processing for the core 61B in accordance with a procedure conforming to IPsec.

[0086] When the authentication of the core 61B is successful in the authentication process of the core 61B, the server 180 creates an IP packet including authentication success information R22 indicating the success of the authentication and including its own IP address and the IP address of the core 61B as the source IP address and the destination IP address, respectively. Then, the server 180 transmits the created IP packet to the in-vehicle relay device 101 via the TCU 202C.

[0087] In the vehicle-mounted relay device 101, the core 61B starts communication with the server 180 by receiving an IP packet including authentication success information R22 from the server 180 via the TCU 202C and the relay unit 52.

[0088] On the other hand, if the server 180 fails to authenticate the core 61B, the server 180 creates an IP packet that includes authentication failure information R23 indicating that the authentication has failed and that includes its own IP address and the IP address of the core 61B as the source IP address and destination IP address, respectively.The server 180 then transmits the created IP packet to the in-vehicle relay device 101 via the TCU 202C.

[0089] In the vehicle-mounted relay device 101, when the core 61B receives the IP packet including the authentication failure information R23 from the server 180 via the TCU 202C and the relay unit 52, it determines that communication with the server 180 is not possible.

[0090] The authentication application 22 may have a function to perform secure communication according to a communication protocol other than TLS. Furthermore, the authentication application 32 may have a function to perform secure communication according to a communication protocol other than IPsec, as long as the communication protocol is different from the communication protocol used in the authentication application 22.

[0091] [Alternative Process] 3 and 5, when the state of core 61A and the state of core 61B are normal and control unit 12 receives a risk notification from server 180 regarding a security risk of core 61A, control unit 12 stops access from server 180 to core 61A and performs substitution processing to have core 61B take over reception of requests from server 180. In the first embodiment of the present disclosure, control unit 12 is realized by relay unit 52 and core 61B shown in FIG.

[0092] More specifically, for example, when a security risk is found in at least one of the LINUX_OS 21 and the authentication application 22 in the core 61A, the server 180 creates an IP packet that includes a risk notification indicating that a security risk has been found in the core 61A and that includes its own IP address and the IP address of the core 61B as the source IP address and the destination IP address, respectively. Then, the server 180 transmits the created IP packet to the TCU 202C via the wireless base station device 161.

[0093] When the TCU 202C receives the IP packet including the risk notification from the server 180, the TCU 202C stores the IP packet in a frame (hereinafter also referred to as a “vulnerability notification frame”) and transmits the frame to the in-vehicle relay device 101.

[0094] In the in-vehicle relay device 101, when the core 61B receives a vulnerability notification frame from the TCU 202C via the relay unit 52, it performs notification processing to output to the relay unit 52 an update notification requesting an update of the routing table Tb1.

[0095] More specifically, for example, the storage unit 62 stores an address table Tb10 that indicates the correspondence between the cores 61 and IP addresses.

[0096] When core 61B receives a vulnerability notification frame from TCU 202C via relay unit 52 while exchanging information with in-vehicle ECU 202 or core 61A, core 61B checks the IP address of core 61A by referring to address table Tb10 in memory unit 62.

[0097] When core 61B confirms the IP address of core 61A, core 61B outputs, as a notification process, an update notification indicating a request to update routing table Tb1, table update information including the IP address of server 180 contained in the vulnerability notification frame, and the confirmed IP address of core 61A to relay unit 52. Note that core 61B may output the table update information to relay unit 52 in a standby state in which no information is exchanged between core 61B and in-vehicle ECU 202 or core 61A.

[0098] When the relay unit 52 receives the table update information from the core 61B, it performs a table update process to update the routing table Tb1.

[0099] More specifically, as a table update process, the relay unit 52 performs a process of changing the relay destination of a frame in the routing table Tb1 whose source IP address is the IP address of the server 180 and whose destination IP address is the IP address of the core 61A. Specifically, for example, the relay unit 52 changes the relay destination of the frame from the core 61A to the core 61B. That is, the relay unit 52 switches the acceptance of access from the server 180 to the core 61A to the core 61B.

[0100] FIG. 8 is a diagram illustrating an example of a routing table after the table update process by the vehicle-mounted relay device according to the first embodiment of the present disclosure.

[0101] 3 and 8, specifically, for example, when relay unit 52 receives table update information from core 61B, relay unit 52 reads out routing table Tb1 in storage unit 62. Then, relay unit 52 changes the port number in routing table Tb1 corresponding to a frame whose source IP address is the IP address of server 180 included in the table update information and whose destination IP address is the IP address of core 61A from "#4" to "#5."

[0102] Furthermore, for example, when the relay unit 52 receives table update information from the core 61B, it performs a list creation process to create a management list L1 that indicates the correspondence between the source IP address included in the frame that changes the relay destination (hereinafter also referred to as the "relay destination change frame") and the destination IP address included in the relay destination change frame.

[0103] FIG. 9 is a diagram illustrating an example of a management list created by a list creation process performed by the vehicle-mounted relay device according to the first embodiment of the present disclosure.

[0104] 9, when relay unit 52 receives table update information from core 61B, it creates a management list L1 indicating relay stop frames whose source IP address is the IP address "IP_Server" of server 180 included in the table update information and whose destination IP address is the IP address "IP_Core A" of core 61A included in the table update information. Then, relay unit 52 stores the created management list L1 in memory unit 62.

[0105] [Continued communication processing] Referring again to FIG. 3, for example, after receiving the risk notification from the server 180, the relay unit 52 further performs a communication continuation process for continuing the communication within the vehicle 1 by the core 61A.

[0106] More specifically, for example, the relay unit 52 continues the communication between the core 61A and the core 61B as the communication continuation process.

[0107] Specifically, for example, when relay unit 52 receives a risk notification from server 180 via TCU 202C and performs table update processing and list creation processing, and then receives a frame from in-vehicle ECU 202, relay unit 52 reads out routing table Tb1 and management list L1 in storage unit 62. Then, relay unit 52 refers to management list L1 to confirm whether the frame received from in-vehicle ECU 202 is a relay stop frame.

[0108] When the frame received from the in-vehicle ECU 202 is a relay stop frame, the relay unit 52 stores, in the payload of the frame, discrimination information indicating that the frame is destined for the core 61A. Then, the relay unit 52 references the routing table Tb1 to output the frame in which the discrimination information is stored to the core 61B.

[0109] After outputting the table update information to the relay unit 52, when the core 61B receives a frame from the relay unit 52, it checks whether or not discrimination information is stored in the payload of the frame.

[0110] If discrimination information is stored in the payload of a frame from the relay unit 52, the core 61B performs a transfer process to output the frame to the core 61A. Upon receiving the frame from the core 61B, the core 61A performs a predetermined process based on various information included in the frame.

[0111] On the other hand, the core 61B determines that transfer processing is unnecessary if discrimination information is not stored in the payload of the frame from the relay unit 52. Then, the core 61B performs predetermined processing based on the various information included in the frame.

[0112] Furthermore, for example, the relay unit 52 continues the communication between the core 61A and the in-vehicle ECU 202 as the communication continuation process.

[0113] More specifically, for example, after receiving a risk notification from the server 180, if the frame received from the vehicle ECU 202 is not a relay stop frame, the relay unit 52 outputs the frame to the destination vehicle ECU 202 or core 61 by referring to the routing table Tb1.

[0114] Specifically, for example, after receiving a risk notification from the server 180, when the relay unit 52 receives a frame addressed to the core 61A from the in-vehicle ECU 202, the relay unit 52 outputs the frame to the addressed core 61A.

[0115] Furthermore, for example, after receiving a risk notification from the server 180, when the relay unit 52 receives a frame addressed to the in-vehicle ECU 202 from the core 61A, the relay unit 52 transmits the frame to the in-vehicle ECU 202 as the destination.

[0116] [Sending information from core 61A to server 180] Furthermore, for example, after receiving a risk notification from the server 180, the relay unit 52 continues transmitting information from the core 61A to the server 180.

[0117] More specifically, for example, after receiving a risk notification from the server 180, when the relay unit 52 receives a frame addressed to the server 180 from the core 61A, the relay unit 52 transmits the frame to the addressed server 180 via the TCU 202C.

[0118] After receiving the risk notification from the server 180, the relay unit 52 may stop transmitting information from the core 61A to the server 180.

[0119] [Operation flow] 10 is a flowchart defining an operation procedure when a core in an in-vehicle relay device according to the first embodiment of the present disclosure performs notification processing. FIG. 10 shows an operation procedure when a core 61B in an in-vehicle relay device 101 performs notification processing.

[0120] 10, when the core 61B's own in-vehicle relay device 101 is started (step S101), the core 61B transmits authentication request information R21 for requesting authentication by the server 180 to the server 180 via the TCU 202C (step S102).

[0121] Next, when core 61B receives authentication success information R22 indicating successful authentication from server 180 (YES in step S103), core 61B starts communication with server 180 (step S104).

[0122] Next, when core 61B receives a risk notification regarding the security risk of core 61A (YES in step S105), it performs a notification process to output to relay unit 21 an update notification indicating a request to update routing table Tb1, table update information including the IP address of server 180 indicated in the risk notification and the IP address of core 61A (step S106).

[0123] Next, the core 61B continues communication with the core 61A. For example, as described above, when the core 61B receives the frame storing the discrimination information from the relay unit 52, the core 61B outputs the frame to the core 61A (step S107).

[0124] On the other hand, when core 61B receives authentication failure information R23 indicating authentication failure from server 180 (NO in step S103), core 61B determines that communication with server 180 is not possible (step S108).

[0125] FIG. 11 is a flowchart defining an operation procedure when the relay unit in the vehicle-mounted relay device according to the first embodiment of the present disclosure performs the table update process and the list creation process.

[0126] 11, first, relay unit 52 waits for table update information from core 61B (NO in step S201), and upon receiving the table update information from core 61B (YES in step S201), performs a table update process to update routing table Tb1. For example, as described above, relay unit 52 changes, in routing table Tb1, the port number corresponding to a frame whose source IP address is the IP address of server 180 included in the table update information received from core 61B and whose destination IP address is the IP address of core 61A included in the table update information, to the port number corresponding to core 61B (step S202).

[0127] Next, the relay unit 52 performs a list creation process to create a management list L1. For example, as described above, the relay unit 52 creates a management list L1 that indicates the correspondence between the source IP address included in the relay destination change frame and the destination IP address included in the relay destination change frame (step S203). Note that steps S202 and S203 may be executed in reverse order or in parallel.

[0128] Next, the relay unit 52 waits for reception of a frame (NO in step S204), and when it receives a frame (YES in step S204), it performs relay processing.

[0129] More specifically, if the received frame is a relay stop frame (YES in step S205), the relay unit 52 outputs the frame to the core 61B. For example, as described above, the relay unit 52 stores, in the payload of the frame, discrimination information indicating that the frame is destined for the core 61A, and outputs the frame to the core 61B (step S206).

[0130] Furthermore, if the source of the received frame is the core 61A (NO in step S205 and YES in step S207), the relay unit 52 transmits the frame to the destination in-vehicle ECU 202 (step S208).

[0131] On the other hand, if the relay unit 52 receives another frame (NO in step S205 and NO in step S207), the relay unit 52 performs relay processing on the other frame (step S209).

[0132] FIG. 12 is a diagram illustrating an example of a sequence of processes performed by the in-vehicle relay device, the in-vehicle ECU, and the server in the communication system according to the first embodiment of the present disclosure.

[0133] 12, first, core 61A transmits authentication request information R11 indicating a request for authentication and its own IP address to server 180 via relay unit 52 and TCU 202C (step S301).

[0134] Next, when the server 180 receives the authentication request information R11 from the in-vehicle relay device 101 via the TCU 202C, it performs authentication processing for the core 61A (step S302).

[0135] Next, if the server 180 successfully authenticates the core 61A, it sends an IP packet to the vehicle-mounted relay device 101 via the TCU202C, which includes authentication success information R12 indicating successful authentication and has its own IP address and the IP address of the core 61A as the source IP address and destination IP address, respectively (step S303).

[0136] Next, when the core 61A in the in-vehicle relay device 101 receives the IP packet including the authentication success information R12 from the server 180 via the TCU 202C and the relay unit 52, it starts communication with the server 180 (step S304).

[0137] Next, the core 61B transmits authentication request information R21 indicating a request for authentication and its own IP address to the server 180 via the relay unit 52 and the TCU 202C (step S305).

[0138] Next, when the server 180 receives the authentication request information R21 from the in-vehicle relay device 101 via the TCU 202C, it performs authentication processing for the core 61B (step S306).

[0139] Next, if the server 180 successfully authenticates the core 61B, it sends an IP packet to the vehicle-mounted relay device 101 via the TCU202C, which includes authentication success information R22 indicating successful authentication and has its own IP address and the IP address of the core 61B as the source IP address and destination IP address, respectively (step S307).

[0140] Next, when the core 61B in the in-vehicle relay device 101 receives the IP packet including the authentication success information R22 from the server 180 via the TCU 202C and the relay unit 52, it starts communication with the server 180 (step S308).

[0141] Next, the server 180 transmits a risk notification regarding the security risk of the core 61A to the in-vehicle relay device 101 via the TCU 202C. For example, as described above, the server 180 transmits an IP packet including the risk notification and including its own IP address and the IP address of the core 61B as the source IP address and the destination IP address, respectively, to the in-vehicle relay device 101 via the TCU 202C (step S309).

[0142] Next, the core 61B in the vehicle-mounted relay device 101 outputs table update information to the relay unit 52, including an update notification requesting an update of the routing table Tb1, the IP address of the server 180 indicated in the risk notification, and the IP address of the core 61A (step S310).

[0143] Next, the relay unit 52 performs a table update process to update the routing table Tb1. For example, as described above, the relay unit 52 changes, in the routing table Tb1, the port number corresponding to a frame whose source IP address is the IP address of the server 180 included in the table update information received from the core 61B and whose destination IP address is the IP address of the core 61A included in the table update information, to the port number corresponding to the core 61B (step S311).

[0144] Next, the relay unit 52 performs a list creation process to create a management list L1. For example, as described above, the relay unit 52 creates a management list L1 indicating the correspondence between the source IP address included in the relay destination change frame and the destination IP address included in the relay destination change frame (step S312). Note that steps S311 and S312 may be executed in reverse order or in parallel.

[0145] Next, the server 180 transmits the frame addressed to the core 61A to the in-vehicle relay device 101 via the TCU 202C (step S313).

[0146] Next, in the vehicle-mounted relay device 101, the relay unit 52 refers to the management list L1 in the memory unit 62 to confirm that the destination IP address contained in the frame received from the server 180 is registered in the management list L1 (step S314).

[0147] Next, the relay unit 52 stores, in the payload of the frame received from the server 180, discrimination information indicating that the frame is addressed to the core 61A, and outputs the frame to the core 61B (step S315).

[0148] Next, when the core 61B receives the frame in which the discrimination information is stored from the relay unit 52, it outputs the frame to the core 61A (step S316).

[0149] Next, the core 61A outputs a frame addressed to a certain in-vehicle ECU 202 to the relay unit 52 (step S317).

[0150] Next, the relay unit 52 transmits the frame received from the core 61A to the destination in-vehicle ECU 202 (step S318).

[0151] <Modification> FIG. 13 is a diagram illustrating an example of a sequence of processes performed by the in-vehicle relay device, the in-vehicle ECU, and the server in the modified example of the communication system according to the first embodiment of the present disclosure.

[0152] The processes from step S401 to step S409 shown in FIG. 13 are similar to the processes from step S301 to step S309 shown in FIG.

[0153] Next, the server 180 transmits a risk notification regarding the security risk of the core 61A to the core 61A in addition to the core 61B. More specifically, the server 180 transmits an IP packet including the risk notification and including its own IP address and the IP address of the core 61A as the source IP address and the destination IP address, respectively, to the in-vehicle relay device 101 via the TCU 202C (step S410).

[0154] Next, in the vehicle-mounted relay device 101, when the core 61A receives the risk notification from the server 180 via the TCU 202C and the relay unit 52, it outputs a reception notification indicating that the risk notification has been received to the core 61B (step S411).

[0155] Next, when core 61B receives a risk notification from server 180 and a receipt notification from core 61A, it outputs to relay unit 52 table update information including an update notification requesting an update of routing table Tb1, the IP address of server 180 indicated in the risk notification, and the IP address of core 61A (step S412).

[0156] The processes from step S413 to step S420 are similar to the processes from step S311 to step S318 shown in FIG.

[0157] In the in-vehicle relay device 101 according to the first embodiment of the present disclosure, the processing unit 53 is configured to include two cores 61, but this is not limited to this. The processing unit 53 may be configured to include three or more cores 61. In this case, after receiving a risk notification about a certain core 61 from the server 180, the relay unit 52 updates the routing table Tb1 and the management list L1 each time it receives a risk notification about a new core 61 from the server 180.

[0158] Furthermore, in the in-vehicle relay device 101 according to the first embodiment of the present disclosure, the routing table Tb1 in the storage unit 62 is not limited to a configuration indicating the correspondence relationship between the source IP address, the destination IP address, and the port number included in the frame, but may be a configuration indicating the correspondence relationship between the source MAC (Media Access Control) address, the destination MAC address, and the port number included in the frame. In this case, when a security risk is found in the core 61A, the server 180 transmits an IP packet including a risk notification and including its own MAC address and the MAC address of the core 61A as the source MAC address and the destination MAC address, respectively, to the in-vehicle relay device 101 via the TCU 202C.

[0159] <Second embodiment> In the first embodiment of the present disclosure described above, the core 61A and the core 61B have different configurations with respect to security, and the control unit 12 that performs alternative processing is realized by the relay unit 52 and the core 61B. In contrast, in the second embodiment of the present disclosure, the in-vehicle ECU 202A and the in-vehicle ECU 202B have different configurations with respect to security, and the control unit that performs alternative processing is realized by the in-vehicle relay device 101 and the in-vehicle ECU 202B. Contents other than those described below are the same as those of the communication system 501 according to the first embodiment.

[0160] 2 also shows the configuration of an in-vehicle system according to the second embodiment of the present disclosure. Referring to Fig. 2, the in-vehicle system 302 includes in-vehicle ECUs 202A, 202B, and 202C, which are in-vehicle ECUs 202, and an in-vehicle relay device 101. Note that the in-vehicle system 302 is not limited to a configuration including three in-vehicle ECUs 202, and may include two or four or more in-vehicle ECUs 202.

[0161] FIG. 14 is a diagram illustrating an example of a routing table stored by the vehicle-mounted relay device according to the second embodiment of the present disclosure.

[0162] 2 and 14, the storage unit 62 in the vehicle-mounted relay device 101 stores a routing table Tb2 used in the relay process.

[0163] In the routing table Tb2, when the in-vehicle relay device 101 receives a frame that includes "IP_Server" and "IP_ECU A" as the source IP address and the destination IP address, respectively, it specifies "#1" as the port number corresponding to the frame. When the in-vehicle relay device 101 receives a frame that includes "IP_Server" and "IP_ECU B" as the source IP address and the destination IP address, respectively, it specifies "#2" as the port number corresponding to the frame. When the in-vehicle relay device 101 receives a frame that includes "IP_ECU A" and "IP_Server" as the source IP address and the destination IP address, respectively, it specifies "#3" as the port number corresponding to the frame. When the in-vehicle relay device 101 receives a frame that includes "IP_ECU B" and "IP_Server" as the source IP address and the destination IP address, respectively, it specifies "#3" as the port number corresponding to the frame.

[0164] 5 also shows functional blocks of the in-vehicle system according to the second embodiment of the present disclosure. Referring to FIG. 5, in the second embodiment of the present disclosure, the first functional unit 11A corresponds to the in-vehicle ECU 202A, and the second functional unit 11B corresponds to the in-vehicle ECU 202B.

[0165] The in-vehicle ECU 202A and the in-vehicle ECU 202B have different configurations with respect to security. In other words, the in-vehicle ECU 202A and the in-vehicle ECU 202B have little relationship with respect to security risks. More specifically, for example, as a difference in configuration with respect to security, the software SW21 used by the in-vehicle ECU 202A is different from the software SW22 used by the in-vehicle ECU 202B. In other words, the software SW21 installed in the in-vehicle ECU 202A is different from the software installed in the in-vehicle ECU 202B.

[0166] Fig. 15 is a diagram illustrating a configuration of first software used by a first functional unit according to a second embodiment of the present disclosure. Fig. 16 is a diagram illustrating a configuration of second software used by a second functional unit according to the second embodiment of the present disclosure.

[0167] 15 and 16, the in-vehicle ECU 202A and the in-vehicle ECU 202B are equipped with, for example, different OSs.

[0168] More specifically, for example, the software SW21 includes a LINUX_OS 21. Note that the software SW21 may include a general-purpose OS other than the LINUX_OS 21.

[0169] For example, the software SW22 includes an OS different from the LINUX_OS 21. Specifically, for example, the software SW22 includes the RTOS 31. Note that the software SW22 may include an OS other than the RTOS 31 as long as the OS is different from the OS included in the software SW21.

[0170] Furthermore, the in-vehicle ECU 202A and the in-vehicle ECU 202B are equipped with, for example, different applications.

[0171] More specifically, for example, the software SW21 includes an authentication application 22, and the software SW22 includes an authentication application 32 that is different from the authentication application 22.

[0172] For example, the function provided by the authentication application 22 included in the software SW21 includes a TLS authentication function that performs secure communication in accordance with the TLS standard.

[0173] Specifically, for example, when the in-vehicle ECU 202A is started, it sends authentication request information R31 indicating its own IP address and requesting authentication to the server 180 via the in-vehicle relay device 101 and the TCU 202C in accordance with a procedure conforming to TLS.

[0174] For example, when the server 180 receives authentication request information R31 from the in-vehicle ECU 202A via the in-vehicle relay device 101 and the TCU 202C, the server 180 performs authentication processing for the in-vehicle ECU 202A in accordance with a procedure conforming to TLS.

[0175] When the server 180 has successfully authenticated the in-vehicle ECU 202A in the authentication process for the in-vehicle ECU 202A, the server 180 creates an IP packet that includes authentication success information R32 indicating successful authentication and that includes the IP address of the server 180 and the IP address of the in-vehicle ECU 202A as the source IP address and the destination IP address, respectively. Then, the server 180 transmits the created IP packet to the in-vehicle ECU 202A via the TCU 202C and the in-vehicle relay device 101.

[0176] When the in-vehicle ECU 202A receives the IP packet including the authentication success information R32 from the server 180 via the TCU 202C and the in-vehicle relay device 101, the in-vehicle ECU 202A starts communication with the server 180.

[0177] On the other hand, if the server 180 fails to authenticate the in-vehicle ECU 202A, the server 180 creates an IP packet that includes authentication failure information R33 indicating the authentication failure and that includes the IP address of the server 180 and the IP address of the in-vehicle ECU 202A as the source IP address and the destination IP address, respectively. Then, the server 180 transmits the created IP packet to the in-vehicle ECU 202A via the TCU 202C and the in-vehicle relay device 101.

[0178] When the in-vehicle ECU 202A receives the IP packet including the authentication failure information R33 from the server 180 via the TCU 202C and the in-vehicle relay device 101, the in-vehicle ECU 202A determines that communication with the server 180 is not possible.

[0179] For example, the function provided by the authentication application 32 included in the software SW22 includes an IPsec authentication function for performing secure communication in accordance with the IPsec standard.

[0180] More specifically, for example, when the in-vehicle ECU 202B is started, it sends authentication request information R41 requesting authentication and indicating its own IP address to the server 180 via the in-vehicle relay device 101 and the TCU 202C in accordance with a procedure conforming to IPsec.

[0181] For example, when the server 180 receives authentication request information R41 from the in-vehicle ECU 202B via the TCU 202C, the server 180 performs authentication processing for the in-vehicle ECU 202B in accordance with a procedure conforming to IPsec.

[0182] When the server 180 has successfully authenticated the in-vehicle ECU 202B in the authentication process for the in-vehicle ECU 202B, the server 180 creates an IP packet that includes authentication success information R42 indicating successful authentication and that includes the IP address of the server 180 and the IP address of the in-vehicle ECU 202B as the source IP address and the destination IP address, respectively. Then, the server 180 transmits the created IP packet to the in-vehicle ECU 202B via the TCU 202C and the in-vehicle relay device 101.

[0183] The in-vehicle ECU 202B starts communication with the server 180 by receiving the IP packet including the authentication success information R42 from the server 180 via the TCU 202C and the in-vehicle relay device 101.

[0184] On the other hand, if the server 180 fails to authenticate the in-vehicle ECU 202B, it generates authentication failure information R43 indicating that the authentication has failed and indicating the IP address of the in-vehicle ECU 202B as the destination IP address, and transmits the generated authentication failure information R43 to the in-vehicle ECU 202B via the TCU 202C and the in-vehicle relay device 101.

[0185] When the in-vehicle ECU 202B receives the IP packet including the authentication failure information R43 from the server 180 via the TCU 202C and the in-vehicle relay device 101, the in-vehicle ECU 202B determines that communication with the server 180 is not possible.

[0186] [Alternative Process] 5, when the state of the in-vehicle ECU 202A and the state of the in-vehicle ECU 202B are normal and the control unit 12 receives a risk notification regarding a security risk of the in-vehicle ECU 202A from the server 180, the control unit 12 stops access from the server 180 to the in-vehicle ECU 202A and performs an alternative process of having the in-vehicle ECU 202B take over the reception from the server 180. In the first embodiment of the present disclosure, the control unit 12 is realized by the in-vehicle relay device 101 and the in-vehicle ECU 202B shown in FIG.

[0187] More specifically, for example, when a security risk is discovered in at least one of the LINUX_OS 21 and the authentication application 22 in the in-vehicle ECU 202A, the server 180 sends an IP packet to the in-vehicle ECU 202B via the TCU 202C and the in-vehicle relay device 101, the IP packet including a risk notification indicating that a security risk has been discovered in the in-vehicle ECU 202A and including its own IP address and the IP address of the in-vehicle ECU 202B as the source IP address and the destination IP address, respectively.

[0188] When the in-vehicle ECU 202B receives the risk notification from the server 180 via the TCU 202C and the in-vehicle relay device 101, the in-vehicle ECU 202B performs notification processing to transmit to the in-vehicle relay device 101 an update notification requesting an update of the routing table Tb2.

[0189] Specifically, for example, a storage unit (not shown) in the in-vehicle ECU 202B stores an address table Tb20 indicating the IP address of the in-vehicle ECU 202A.

[0190] For example, when the in-vehicle ECU 202B is exchanging information with other devices and receives a risk notification from the server 180 via the TCU 202C and the in-vehicle relay device 101, the in-vehicle ECU 202B checks the IP address of the in-vehicle ECU 202A by referring to the address table Tb20 in its own memory.

[0191] When the in-vehicle ECU 202B confirms the IP address of the in-vehicle ECU 202A, as a notification process, the in-vehicle ECU 202B creates a table update frame including an update notification indicating a request to update the routing table Tb2, the IP address of the server 180 indicated in the risk notification, and the confirmed IP address of the in-vehicle ECU 202A, and transmits the table update frame to the in-vehicle relay device 101. Note that the in-vehicle ECU 202B may transmit the table update frame to the in-vehicle relay device 101 in a standby state in which it is not exchanging information with other in-vehicle ECUs 202.

[0192] When the in-vehicle relay device 101 receives the table update frame from the in-vehicle ECU 202B, it performs a table update process to update the routing table Tb2.

[0193] More specifically, as a table update process, the in-vehicle relay device 101 performs a process of changing the relay destination of a frame in the routing table Tb2, the source IP address of which is the IP address of the server 180 and the destination IP address of which is the IP address of the in-vehicle ECU 202A. Specifically, for example, the in-vehicle relay device 101 changes the relay destination of the frame from the in-vehicle ECU 202A to the in-vehicle ECU 202B. That is, the in-vehicle relay device 101 substitutes the in-vehicle ECU 202B for accepting access from the server 180 to the in-vehicle ECU 202A.

[0194] FIG. 17 is a diagram illustrating an example of a routing table after the table update process by the vehicle-mounted relay device according to the second embodiment of the present disclosure.

[0195] 2 and 17, specifically, for example, when the in-vehicle relay device 101 receives a table update frame from the in-vehicle ECU 202B, the in-vehicle relay device 101 reads out the routing table Tb2 in the storage unit 62. Then, in the routing table Tb2, the in-vehicle relay device 101 changes the port number corresponding to a frame whose source IP address is the IP address of the server 180 included in the table update frame and whose destination IP address is the IP address of the in-vehicle ECU 202A from "#1" to "#2."

[0196] Also, for example, when the in-vehicle relay device 101 receives a table update frame from the in-vehicle ECU 202B, it performs a list creation process to create a management list L2 that shows the correspondence between the source IP address contained in the relay destination change frame and the destination IP address contained in the relay destination change frame.

[0197] FIG. 18 is a diagram illustrating an example of a management list created by a list creation process performed by an in-vehicle relay device according to the second embodiment of the present disclosure.

[0198] 18, when in-vehicle relay device 101 receives a table update frame from in-vehicle ECU 202B, it creates a management list L2 indicating a relay stop frame whose source IP address is "IP_Server," the IP address of server 180 included in the table update frame, and whose destination IP address is "IP_ECU A," the IP address of in-vehicle ECU 202A included in the table update frame. Then, in-vehicle relay device 101 stores the created management list L2 in memory unit 62.

[0199] [Continued communication processing] Referring again to FIG. 2, for example, after receiving the risk notification from the server 180, the in-vehicle relay device 101 further performs a communication continuation process for continuing the communication within the vehicle 1 by the in-vehicle ECU 202A.

[0200] More specifically, for example, the in-vehicle relay device 101 continues the communication between the in-vehicle ECU 202A and the in-vehicle ECU 202B as the communication continuation process.

[0201] Specifically, for example, when the in-vehicle relay device 101 receives a risk notification from the server 180, performs a table update process and a list creation process, and then receives a frame from a certain in-vehicle ECU 202, it reads out the routing table Tb2 and the management list L2 in the storage unit 62. Then, the in-vehicle relay device 101 checks whether the received frame is a relay stop frame by referring to the management list L2.

[0202] When a frame received from an in-vehicle ECU 202 is a relay stop frame, the in-vehicle relay device 101 stores, in the payload of the frame, discrimination information indicating that the frame is destined for the in-vehicle ECU 202A. Then, the in-vehicle relay device 101 refers to the routing table Tb2 and transmits the frame storing the discrimination information to the in-vehicle ECU 202B.

[0203] After transmitting the table update frame to the in-vehicle relay device 101, when the in-vehicle ECU 202B receives a frame from the in-vehicle relay device 101, the in-vehicle ECU 202B checks whether or not discrimination information is stored in the payload of the frame.

[0204] When the discrimination information is stored in the payload of the frame from the in-vehicle relay device 101, the in-vehicle ECU 202B performs a transfer process of transmitting the frame to the in-vehicle ECU 202A via the in-vehicle relay device 101.

[0205] Specifically, for example, the in-vehicle ECU 202B changes the destination IP address of the frame that stores the discrimination information and that is received from the in-vehicle relay device 101, from its own IP address to the IP address of the in-vehicle ECU 202A. Then, the in-vehicle ECU 202B transmits the frame with the changed destination IP address to the in-vehicle relay device 101. The in-vehicle relay device 101 transmits the frame received from the in-vehicle ECU 202B to the in-vehicle ECU 202A.

[0206] When the in-vehicle ECU 202A receives a frame from the in-vehicle ECU 202B via the in-vehicle relay device 101, the in-vehicle ECU 202A performs a predetermined process based on various information included in the frame.

[0207] On the other hand, the in-vehicle ECU 202B determines that the transfer process is unnecessary if the discrimination information is not stored in the payload of the frame from the in-vehicle relay device 101. Then, the in-vehicle ECU 202B performs a predetermined process based on various information included in the frame.

[0208] Furthermore, for example, the in-vehicle relay device 101 continues the communication between the in-vehicle ECU 202A and the in-vehicle ECU 202C as the communication continuation process.

[0209] More specifically, for example, after receiving a risk notification from the server 180, if the frame received from a certain vehicle ECU 202 is not a relay stop frame, the vehicle relay device 101 transmits the frame to the destination vehicle ECU 202 by referring to the routing table Tb2.

[0210] Specifically, for example, after receiving a risk notification from the server 180, when the in-vehicle relay device 101 receives a frame addressed to the in-vehicle ECU 202C from the in-vehicle ECU 202A, the in-vehicle relay device 101 transmits the frame to the in-vehicle ECU 202C as the destination.

[0211] Furthermore, for example, after receiving a risk notification from the server 180, when the in-vehicle relay device 101 receives a frame addressed to the in-vehicle ECU 202A from the in-vehicle ECU 202C, the in-vehicle relay device 101 transmits the frame to the in-vehicle ECU 202A as the destination.

[0212] [Transmission of information from in-vehicle ECU 202A to server 180] Furthermore, for example, after receiving a risk notification from the server 180, the in-vehicle relay device 101 continues transmitting information from the in-vehicle ECU 202A to the server 180.

[0213] More specifically, for example, after receiving a risk notification from server 180, when vehicle-mounted relay device 101 receives a frame addressed to server 180 from vehicle-mounted ECU 202A, it transmits the frame to the addressed server 180 via TCU 202C.

[0214] After receiving the risk notification from the server 180, the in-vehicle relay device 101 may stop transmitting information from the in-vehicle ECU 202A to the server 180.

[0215] FIG. 19 is a diagram illustrating an example of a sequence of processes performed by the in-vehicle relay device, the in-vehicle ECU, and the server in the communication system according to the second embodiment of the present disclosure.

[0216] 19, first, the in-vehicle ECU 202A transmits authentication request information R31 indicating a request for authentication and its own IP address to the server 180 via the in-vehicle relay device 101 and the TCU 202C (step S501).

[0217] Next, when the server 180 receives the authentication request information R31 from the in-vehicle ECU 202A via the in-vehicle relay device 101 and the TCU 202C, it performs authentication processing for the in-vehicle ECU 202A (step S502).

[0218] Next, when the server 180 has successfully authenticated the in-vehicle ECU 202A, the server 180 transmits authentication success information R32 indicating the authentication success and the IP address of the in-vehicle ECU 202A as the destination IP address to the in-vehicle ECU 202A via the TCU 202C and the in-vehicle relay device 101 (step S503).

[0219] Next, when the in-vehicle ECU 202A receives the authentication success information R32 from the server 180 via the TCU 202C and the in-vehicle relay device 101, the in-vehicle ECU 202A starts communication with the server 180 (step S504).

[0220] Next, the in-vehicle ECU 202B transmits authentication request information R41 requesting authentication and indicating its own IP address to the server 180 via the in-vehicle relay device 101 and the TCU 202C (step S505).

[0221] Next, when the server 180 receives the authentication request information R41 from the in-vehicle relay device 101 via the TCU 202C, it performs authentication processing for the in-vehicle ECU 202B (step S506).

[0222] Next, when the server 180 has successfully authenticated the in-vehicle ECU 202B, the server 180 transmits authentication success information R42 indicating the authentication success and the IP address of the in-vehicle ECU 202B as the destination IP address to the in-vehicle ECU 202B via the TCU 202C (step S507).

[0223] Next, when the in-vehicle ECU 202B receives the authentication success information R42 from the server 180 via the TCU 202C and the in-vehicle relay device 101, the in-vehicle ECU 202B starts communication with the server 180 (step S508).

[0224] Next, the server 180 transmits a risk notification regarding the security risk of the in-vehicle ECU 202A to the in-vehicle ECU 202B via the TCU 202C and the in-vehicle relay device 101. For example, as described above, the server 180 transmits an IP packet including the risk notification and including its own IP address and the IP address of the in-vehicle ECU 202B as the source IP address and the destination IP address, respectively, to the in-vehicle ECU 202B via the TCU 202C and the in-vehicle relay device 101 (step S509).

[0225] Next, the in-vehicle ECU 202B transmits a table update frame to the in-vehicle relay device 101, which includes an update notification requesting an update of the routing table Tb2, the IP address of the server 180 indicated in the risk notification, and the IP address of the in-vehicle ECU 202A (step S510).

[0226] Next, the in-vehicle relay device 101 performs a table update process to update the routing table Tb2. For example, as described above, the in-vehicle relay device 101 changes, in the routing table Tb2, the port number corresponding to a frame in which the IP address of the server 180 included in the table update frame received from the in-vehicle ECU 202B is the source IP address and the IP address of the in-vehicle ECU 202A included in the table update frame is the destination IP address, to the port number corresponding to the in-vehicle ECU 202B (step S511).

[0227] Next, the in-vehicle relay device 101 performs a list creation process to create a management list L2 that indicates a relay destination change frame. For example, as described above, the in-vehicle relay device 101 creates a management list L2 that indicates a relay stop frame whose source IP address is the IP address of the server 180 and whose destination IP address is the IP address of the in-vehicle ECU 202A (step S512). Note that steps S511 and S512 may be executed in reverse order or in parallel.

[0228] Next, the server 180 transmits a frame addressed to the in-vehicle ECU 202A to the in-vehicle relay device 101 via the TCU 202C (step S513).

[0229] Next, the vehicle-mounted relay device 101 refers to the management list L2 in the storage unit 62 to confirm that the destination IP address included in the frame received from the server 180 is registered in the management list L2 (step S514).

[0230] Next, the in-vehicle relay device 101 stores, in the payload of the frame received from the server 180, discrimination information indicating that the frame is addressed to the in-vehicle ECU 202A, and transmits the frame to the in-vehicle ECU 202B (step S515).

[0231] Next, when the in-vehicle ECU 202B confirms that discrimination information is stored in the frame received from the in-vehicle relay device 101, it changes the destination IP address of the frame to the IP address of the in-vehicle ECU 202A and sends it to the in-vehicle relay device 101 (step S516).

[0232] Next, the in-vehicle relay device 101 transmits the frame received from the in-vehicle ECU 202B to the in-vehicle ECU 202A (step S517).

[0233] Next, the in-vehicle ECU 202A outputs the frame addressed to the in-vehicle ECU 202C to the relay unit 52 (step S518).

[0234] Next, the in-vehicle relay device 101 transmits the frame received from the in-vehicle ECU 202A to the destination in-vehicle ECU 202C (step S519).

[0235] In the in-vehicle systems 301 and 302 according to the embodiments of the present disclosure, the control unit 12 is configured to perform a communication continuation process to continue communication within the vehicle 1 by the first functional unit 11A after receiving a risk notification from the server 180, but this is not limited to this. The control unit 12 may be configured to stop communication within the vehicle 1 by the first functional unit 11A after receiving a risk notification from the server 180.

[0236] In addition, in the in-vehicle systems 301 and 302 according to the embodiment of the present disclosure, the software used by the first functional unit 11A and the software used by the second functional unit 11B are different from each other as a configuration different in terms of security, but this is not limited to this. In the in-vehicle systems 301 and 302, the hardware used by the first functional unit 11A and the hardware used by the second functional unit 11B may be different from each other as a configuration different in terms of security.

[0237] Furthermore, in the in-vehicle systems 301 and 302 according to the embodiments of the present disclosure, the control unit 12 is configured to continue transmitting information from the first functional unit 11A to the server 180 after receiving a risk notification about the first functional unit 11A from the server 180, but this is not limited to this. The control unit 12 may be configured to stop transmitting information from the first functional unit 11A to the server 180 after receiving the risk notification from the server 180.

[0238] The above-described embodiments should be considered to be illustrative in all respects and not restrictive. The scope of the present invention is defined by the claims, not by the above description, and is intended to include all modifications within the meaning and scope of the claims.

[0239] Each process (each function) in the above-described embodiments is realized by a processing circuit including one or more processors. The processing circuit may be configured as an integrated circuit or the like that combines one or more memories, various analog circuits, and various digital circuits in addition to the one or more processors. The one or more memories store programs (instructions) that cause the one or more processors to execute each of the processes. The one or more processors may execute each of the processes according to the programs read from the one or more memories, or according to logic circuits pre-designed to execute each of the processes. The processor may be various processors suitable for computer control, such as a central processing unit (CPU), a graphics processing unit (GPU), a digital signal processor (DSP), a field programmable gate array (FPGA), and an application-specific integrated circuit (ASIC). Note that the physically separate processors may cooperate with each other to execute each of the processes. For example, the processors mounted on a plurality of physically separated computers may cooperate with each other to execute the above processes via a network such as a LAN (Local Area Network), a WAN (Wide Area Network), the Internet, etc. The program may be installed into the memory from an external server device or the like via the network, or may be distributed in a state stored on a recording medium such as a CD-ROM (Compact Disc Read Only Memory), a DVD-ROM (Digital Versatile Disc Read Only Memory), or a semiconductor memory, and installed into the memory from the recording medium. [Explanation of symbols]

[0240] 1 vehicle 10 Ethernet cables 11A First functional part 11B Second functional unit 12 Control Unit 21 LINUX_OS 22,32 Authentication Applications 31 RTOS 51 communication port 52 Relay Section 53 Processing section 61, 61A, 61B Core 62 Storage section 101 Vehicle relay device 161 Wireless base station equipment 170 External Network 180 servers 202,202A,202B,202C Automotive ECU 301,302 In-Vehicle Systems 401 In-Vehicle Network 501 Communication Systems SW11, SW12, SW21, SW22 software

Claims

1. An in-vehicle system mounted on a vehicle, a plurality of functional units including a first functional unit and a second functional unit having different configurations with respect to security; an in-vehicle system comprising: a control unit that, when the state of the first functional unit and the state of the second functional unit are normal and a risk notification regarding a security risk of the first functional unit is received from an external device outside the vehicle, stops access to the first functional unit from the external device and performs alternative processing to have the second functional unit accept the access instead.

2. The in-vehicle system according to claim 1 , wherein the control unit further performs a communication continuation process for continuing communication within the vehicle by the first function unit after receiving the risk notification from the external device.

3. 3. The in-vehicle system according to claim 2, wherein the control unit continues communication between the first functional unit and other functional units among the plurality of functional units other than the first functional unit and the second functional unit as the communication continuation process.

4. The in-vehicle system according to claim 2 or 3, wherein the control unit continues the communication between the first function unit and the second function unit as the communication continuation process.

5. 3. The in-vehicle system according to claim 1, wherein the first software used by the first functional unit and the second software used by the second functional unit are different.

6. the function provided by the first software includes a function for performing secure communication according to a first communication protocol; The in-vehicle system according to claim 5 , wherein the function provided by the second software includes a function for performing the secure communication in accordance with a second communication protocol different from the first communication protocol.

7. the first software includes a first application; The in-vehicle system of claim 5 , wherein the second software includes a second application that is different from the first application.

8. the first software includes a first OS (Operating System); The in-vehicle system according to claim 5 , wherein the second software includes a second OS different from the first OS.

9. A security management method for an in-vehicle system mounted on a vehicle, the in-vehicle system having a plurality of functional units including a first functional unit and a second functional unit having different security configurations, the method comprising: receiving a risk notification regarding a security risk of the first functional unit from an external device outside the vehicle when the state of the first functional unit and the state of the second functional unit are normal; When the risk notification is received, the security management method includes a step of stopping access from the external device to the first functional unit and performing alternative processing to have the second functional unit accept the access instead.

10. A security management program used in an in-vehicle system mounted on a vehicle, the in-vehicle system having a plurality of functional units including a first functional unit and a second functional unit having different security configurations, the program comprising: Computer, a control unit that, when a risk notification regarding a security risk of the first functional unit is received from an external device outside the vehicle while the first functional unit and the second functional unit are in a normal state, stops access to the first functional unit from the external device and performs an alternative process of causing the second functional unit to accept the access instead; A security management program that functions as a

Images