In-vehicle relay device, management device, in-vehicle system, and communication management method

Abstract

This on-vehicle relay device comprises: a relay unit that performs a relay process for transmitting a plurality of frames respectively received from a plurality of on-vehicle devices to destination on-vehicle devices; a determination unit that determines whether a frame, of the frames, includes a start request of a communication session between the on-vehicle devices and whether the frames include start responses to the start request; a generation unit that generates, for each session, a common key for use in the session participated by an on-vehicle device which is a transmission source of the frame determined to include the start request by the determination unit and one or more on-vehicle devices which are transmission sources of the frames determined to include the start responses by the determination unit; and a transmission unit that transmits the common key through the relay unit to each on-vehicle device which will participate in the session.

Description

Technical Field

[0001] The present disclosure relates to an in-vehicle relay device, a management device, an in-vehicle system, and a communication management method. This application claims priority based on Japanese Patent Application No. 2021-39794 filed on March 12, 2021, and Japanese Patent Application No. 2021-134479 filed on August 20, 2021, and incorporates all of the disclosures thereof herein.

Background Art

[0002] Patent Document 1 (Japanese Unexamined Patent Application Publication No. 2018-26791) discloses a frame transmission blocking device as follows. That is, the frame transmission blocking device is a frame transmission blocking device connected to a bus in a network system in which a plurality of electronic control units communicate via the bus, and includes a receiving unit that receives a frame from the bus, and a processing unit that switches whether to execute a predetermined process of blocking the transmission of the frame received by the receiving unit when the frame satisfies a predetermined condition based on management information indicating whether to allow the blocking of the frame transmission.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

[0004] The in-vehicle relay device of the present disclosure includes a relay unit that performs relay processing for transmitting a plurality of frames received from a plurality of in-vehicle devices to the destination in-vehicle device respectively, a determination unit that determines that the plurality of frames include a start request for a communication session between the plurality of in-vehicle devices and a start response to the start request, a generation unit that generates a common key for each session used by the in-vehicle device that is the transmission source of the frame determined by the determination unit to include the start request and one or more of the in-vehicle devices that are the transmission sources of the frames determined by the determination unit to include the start response, and a transmission unit that transmits the common key to each in-vehicle device participating in the session via the relay unit.

[0005] The management device of the present disclosure is a management device used in an in-vehicle system including a plurality of in-vehicle devices, and includes a reception unit that receives, from the plurality of in-vehicle devices, a start request for a communication session between a plurality of the in-vehicle devices that are some or all of the plurality of in-vehicle devices and a start response to the start request, a generation unit that generates a common key unique to the session for use in the session associated with the start request and the start response, and a transmission unit that transmits the common key to each in-vehicle device participating in the session.

[0006] The in-vehicle system of the present disclosure includes a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, and an in-vehicle relay device. The in-vehicle relay device performs a relay process of transmitting a plurality of frames respectively received from the plurality of in-vehicle devices to the destination in-vehicle device. The first in-vehicle device transmits a first frame including a request to start a communication session between a plurality of the in-vehicle devices that are part or all of the plurality of in-vehicle devices to the in-vehicle relay device. The second in-vehicle device transmits a second frame including a start response to the start request to the in-vehicle relay device. The in-vehicle relay device generates a common key for each session used by the session in which the first in-vehicle device that is the source of the received first frame and the second in-vehicle device that is the source of the received second frame participate, and transmits the generated common key to each in-vehicle device participating in the session.

[0007] The in-vehicle system of the present disclosure includes a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, and a management device. The first in-vehicle device transmits a request to start a communication session between a plurality of the in-vehicle devices that are part or all of the plurality of in-vehicle devices to the management device. The second in-vehicle device transmits a start response to the start request to the management device. The management device generates a common key unique to the session used for the session associated with the received start request and the start response, and transmits the generated common key to each in-vehicle device participating in the session.

[0008] The communication management method of the present disclosure is a communication management method in an in-vehicle relay device that performs relay processing for transmitting a plurality of frames received from a plurality of in-vehicle devices to the in-vehicle device of the destination, respectively, wherein the plurality of frames include a start request for a session of communication between the plurality of in-vehicle devices, and a step of determining that the plurality of frames include a start response to the start request, a step of generating a common key for the session in which the in-vehicle device that is the transmission source of the frame determined to include the start request and one or a plurality of the in-vehicle devices that are the transmission sources of the frames determined to include the start response participate, for each session, and a step of transmitting the generated common key to each in-vehicle device participating in the session.

[0009] The communication management method of the present disclosure is a communication management method in a management device used in an in-vehicle system including a plurality of in-vehicle devices, including a step of receiving, from the plurality of in-vehicle devices, a start request for a session of communication between a plurality of the in-vehicle devices that are some or all of the plurality of in-vehicle devices, and a start response to the start request, respectively, a step of generating a common key unique to the session for use in the session associated with the received start request and the start response, and a step of transmitting the generated common key to each in-vehicle device participating in the session.

[0010] The communication management method of the present disclosure is a communication management method in a vehicle-mounted system including a plurality of vehicle-mounted devices including a first vehicle-mounted device and a second vehicle-mounted device, and a vehicle-mounted relay device that performs relay processing of transmitting a plurality of frames received from the plurality of vehicle-mounted devices to the vehicle-mounted device of the destination, respectively. The method includes: a step in which the first vehicle-mounted device transmits a first frame including a start request for a communication session between a plurality of the vehicle-mounted devices that are part or all of the plurality of vehicle-mounted devices to the vehicle-mounted relay device; a step in which the second vehicle-mounted device transmits a second frame including a start response to the start request to the vehicle-mounted relay device; and a step in which the vehicle-mounted relay device generates a common key for the session in which the first vehicle-mounted device that is the transmission source of the received first frame and the second vehicle-mounted device that is the transmission source of the received second frame participate, for each session, and transmits the generated common key to each vehicle-mounted device participating in the session.

[0011] The communication management method of the present disclosure is a communication management method in a vehicle-mounted system including a plurality of vehicle-mounted devices including a first vehicle-mounted device and a second vehicle-mounted device, and a management device. The method includes: a step in which the first vehicle-mounted device transmits a start request for a communication session between a plurality of the vehicle-mounted devices that are part or all of the plurality of vehicle-mounted devices to the management device; a step in which the second vehicle-mounted device transmits a start response to the start request to the management device; and a step in which the management device generates a common key unique to the session, which is used for the session associated with the received start request and the start response, and transmits the generated common key to each vehicle-mounted device participating in the session.

[0012] One aspect of the present disclosure can be realized not only as an in-vehicle relay device including such a characteristic processing unit, but also as a semiconductor integrated circuit realizing part or all of the in-vehicle relay device, or as a program for causing a computer to execute processing steps in the in-vehicle relay device, or as a semiconductor integrated circuit realizing part or all of an in-vehicle system including the in-vehicle relay device, or as a program for causing a computer to execute processing steps in the in-vehicle system.

[0013] One aspect of the present disclosure can be realized not only as a management device including such a characteristic processing unit, but also as a semiconductor integrated circuit realizing part or all of the management device, or as a program for causing a computer to execute processing steps in the management device, or as a semiconductor integrated circuit realizing part or all of an in-vehicle system including the management device, or as a program for causing a computer to execute processing steps in the in-vehicle system.

Brief Description of the Drawings

[0014]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Mode for Carrying Out the Invention

[0015] Conventionally, technologies for improving security in in-vehicle networks have been developed.

[0016] [Problems to be Solved by the Present Disclosure] In the frame transmission prevention device described in Patent Document 1, an illegal message is detected based on the content of a data frame, that is, a message, transmitted and received in an ECU (Electronic Control Unit), and the transmission and reception cycle of the message.

[0017] By the way, in recent years, the development of in-vehicle systems that perform service-oriented communication has advanced. In such an in-vehicle system, sudden messages and messages that do not include a payload are transmitted and received. In the frame transmission prevention device described in Patent Document 1, there has been a problem that it is difficult to detect an illegal message in an in-vehicle system in which sudden messages and messages that do not include a payload are transmitted and received.

[0018] The present disclosure has been made to solve the above-described problems, and an object thereof is to provide an in-vehicle relay device, a management device, an in-vehicle system, and a communication management method capable of further improving security in an in-vehicle network.

[0019] [Effects of the Present Disclosure] According to the present disclosure, security in an in-vehicle network can be further improved.

[0020] [Description of Embodiments of the Present Disclosure] First, the content of the embodiments of the present disclosure will be listed and described.

[0021] (1) The in-vehicle relay device according to an embodiment of the present disclosure includes a relay unit that performs a relay process of transmitting a plurality of frames received from a plurality of in-vehicle devices to the destination in-vehicle device respectively, a determination unit that determines that the plurality of frames include a start request for a communication session between the plurality of in-vehicle devices and include a start response to the start request, a generation unit that generates a common key for each session used by the in-vehicle device that is the transmission source of the frame determined by the determination unit to include the start request and one or more of the in-vehicle devices that are the transmission sources of the frames determined by the determination unit to include the start response, and a transmission unit that transmits the common key to each in-vehicle device participating in the session via the relay unit.

[0022] In this way, in the in-vehicle relay device, it is determined that the received frame includes a start request and that the received frame includes a start response, and a common key used for a session in which the in-vehicle device that is the transmission source of the frame including the start request and one or more of the in-vehicle devices that are the transmission sources of the frames including the start response participate is generated for each session and transmitted to each in-vehicle device. Thus, communication using an individual common key for each session can be performed between in-vehicle devices, so that the security of communication between in-vehicle devices can be improved. Also, for example, by performing authentication of the in-vehicle device that is the transmission source of the start request and the in-vehicle device that is the transmission source of the start response and then generating and transmitting the common key, participation in the session by unauthorized devices can be prevented. Therefore, the security in the in-vehicle network can be further improved.

[0023] (2) The in-vehicle relay device may further include a storage unit that stores the unique ID of each in-vehicle device, and the transmission unit may be configured to transmit, via the relay unit, the common key encrypted using one of the unique IDs as an encryption key to the in-vehicle device having the unique ID used for the encryption.

[0024] With such a configuration, only legitimate in-vehicle devices that can participate in the session can decrypt the common key, so it is possible to prevent, for example, the leakage of the common key to unauthorized in-vehicle devices.

[0025] (3) The transmission unit may be configured to further transmit, via the relay unit, to the in-vehicle device having the unique ID used for calculating the hash value, the hash value calculated using one of the unique IDs and the common key.

[0026] With such a configuration, in the in-vehicle device that has received the common key from the in-vehicle relay device, by comparing the hash value calculated using its own unique ID and the common key received from the in-vehicle relay device with the hash value received from the in-vehicle relay device, it is possible to confirm whether the common key received from the in-vehicle relay device has been tampered with.

[0027] (4) The in-vehicle relay device may further include a recording unit that records session information regarding the session in which the common key is used.

[0028] With such a configuration, the session information recorded by the in-vehicle relay device can be used, for example, in digital forensics. Also, without giving each in-vehicle device the function of storing session information, session information regarding a plurality of sessions can be aggregated in the in-vehicle relay device, so that, for example, session information regarding all sessions started in the in-vehicle system can be recorded with a simple configuration.

[0029] (5) The recording unit may be configured to record, as the session information, the transmission time of the common key by the relay unit.

[0030] With such a configuration, the in-vehicle relay device can record the start of the session.

[0031] (6) The determination unit determines that the frame received by the relay unit includes an end request for the session, and the recording unit may be configured to record, as the session information, the reception time of the frame including the end request by the relay unit.

[0032] With such a configuration, the in-vehicle relay device can record the end of the session.

[0033] (7) The determination unit determines the propriety of the frame according to the determination result that the frame received by the relay unit includes the start request or the start response, and the relay unit may be configured to perform the relay process or discard of the frame according to the determination result of the propriety of the frame by the determination unit.

[0034] With such a configuration, it is possible to detect start requests and start responses from unauthorized devices and prevent unauthorized devices from participating in the session.

[0035] (8) The management device according to an embodiment of the present disclosure is a management device used in an in-vehicle system including a plurality of in-vehicle devices, and includes a reception unit that receives, from the plurality of in-vehicle devices, start requests for a session of communication between some or all of the plurality of in-vehicle devices, and start responses to the start requests, a generation unit that generates a common key unique to the session for use in the session associated with the start requests and the start responses, and a transmission unit that transmits the common key to each of the in-vehicle devices participating in the session.

[0036] In this way, by receiving the session start request and start response from the in-vehicle device, generating a common key unique to the session to be used in the session, and transmitting it to each in-vehicle device, communication using an individual common key can be performed for each session between in-vehicle devices. Therefore, the security of communication between in-vehicle devices can be improved. Also, for example, by authenticating the in-vehicle device that is the source of the start request, it is possible to detect a start request from an unauthorized device. Thus, the security in the in-vehicle network can be further improved.

[0037] (9) The management device may further include a storage unit that stores the unique ID of each in-vehicle device, and the transmission unit may transmit the common key encrypted using one of the unique IDs as an encryption key to the in-vehicle device having the unique ID used for the encryption.

[0038] With such a configuration, only legitimate in-vehicle devices that can participate in the session can decrypt the common key. Therefore, for example, leakage of the common key to unauthorized in-vehicle devices can be prevented.

[0039] (10) The transmission unit may further transmit a hash value calculated using one of the unique IDs and the common key to the in-vehicle device having the unique ID used for the calculation of the hash value.

[0040] With such a configuration, in the in-vehicle device that has received the common key from the management device, by comparing the hash value calculated using its own unique ID and the common key received from the management device with the hash value received from the management device, it is possible to confirm whether the common key received from the management device has been tampered with.

[0041] (11) The reception unit receives the session end request from the in-vehicle device, and based on the reception of the end request by the reception unit, the transmission unit may transmit an end instruction to end the session to the other in-vehicle devices participating in the session.

[0042] With such a configuration, since the management device is involved in the termination of the session and can record the in-vehicle device that is the source of the termination request and the termination time of the session, the recorded information can be used, for example, in digital forensics.

[0043] (12) The management device may further have a configuration including a recording unit that records session information regarding the session in which the common key is used.

[0044] With such a configuration, the session information recorded by the management device can be used, for example, in digital forensics. Also, without giving each in-vehicle device the function of storing session information, the session information regarding a plurality of sessions can be aggregated in the management device, so that, for example, the session information regarding all sessions started in the in-vehicle system can be recorded with a simple configuration.

[0045] (13) The recording unit may record, as the session information, the transmission time of the common key by the transmission unit.

[0046] With such a configuration, the management device can record the start of the session.

[0047] (14) The management device further includes a recording unit that records session information regarding the session in which the common key is used, and the recording unit may record, as the session information, the reception time of the termination request by the reception unit.

[0048] With such a configuration, the management device is involved in the termination of the session and can record the termination of the session.

[0049] (15) The in-vehicle system according to an embodiment of the present disclosure includes a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, and an in-vehicle relay device. The in-vehicle relay device performs a relay process of transmitting a plurality of frames respectively received from the plurality of in-vehicle devices to the in-vehicle device of the destination. The first in-vehicle device transmits a first frame including a start request for a communication session between a plurality of the in-vehicle devices that are some or all of the plurality of in-vehicle devices to the in-vehicle relay device. The second in-vehicle device transmits a second frame including a start response to the start request to the in-vehicle relay device. The in-vehicle relay device generates a common key for each session used in the session in which the first in-vehicle device that is the transmission source of the received first frame and the second in-vehicle device that is the transmission source of the received second frame participate, and transmits the generated common key to each in-vehicle device participating in the session.

[0050] In this way, since the first in-vehicle device transmits a start request to the in-vehicle relay device, the second in-vehicle device transmits a start response to the in-vehicle relay device, and the in-vehicle relay device generates a common key for each session used in the session in which the first in-vehicle device and the second in-vehicle device participate and transmits it to each in-vehicle device, communication using an individual common key can be performed for each session between the in-vehicle devices, so that the security of communication between the in-vehicle devices can be improved. Also, for example, by performing authentication of the in-vehicle device that is the transmission source of the start request and the in-vehicle device that is the transmission source of the start response and then generating and transmitting the common key, it is possible to prevent unauthorized devices from participating in the session. Therefore, the security in the in-vehicle network can be further improved.

[0051] (16) The in-vehicle relay device, the first in-vehicle device, and the second in-vehicle device may be configured to be connected without passing through another relay device.

[0052] With such a configuration, in the in-vehicle relay device, since it is possible to receive the frames transmitted by the first in-vehicle device and the frames transmitted by the second in-vehicle device, it is possible to easily generate and transmit the common key of the session in which the first in-vehicle device and the second in-vehicle device participate.

[0053] (17) When detecting an abnormality in the in-vehicle system while the in-vehicle device is transmitting information to a plurality of the in-vehicle devices by multicast, the in-vehicle device may switch to a state of transmitting information to the plurality of the in-vehicle devices by unicast.

[0054] With such a configuration, in the in-vehicle system, even when an abnormality such as intrusion by an unauthorized device occurs, it is possible to maintain a state in which secure communication is possible at least between legitimate in-vehicle devices.

[0055] (18) The in-vehicle relay device includes a storage unit that stores the unique ID of each in-vehicle device in the in-vehicle system. The in-vehicle relay device further transmits a hash value calculated using one of the unique IDs and the common key to the in-vehicle device having the unique ID used for the calculation of the hash value. The in-vehicle device may collate the hash value calculated using the common key received from the in-vehicle relay device and its own unique ID with the hash value received from the in-vehicle relay device.

[0056] With such a configuration, in the in-vehicle device, based on the collation result between the calculated hash value and the hash value received from the in-vehicle relay device, it is possible to confirm whether the common key received from the in-vehicle relay device has been tampered with.

[0057] (19) The in-vehicle system according to an embodiment of the present disclosure includes a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, and a management device. The first in-vehicle device transmits a start request for a communication session between some or all of the plurality of in-vehicle devices to the management device. The second in-vehicle device transmits a start response to the start request to the management device. The management device generates a common key unique to the session, which is used for the session associated with the received start request and the start response, and transmits the generated common key to each in-vehicle device participating in the session.

[0058] In this way, since the first in-vehicle device transmits a start request for a session to the management device, the second in-vehicle device transmits a start response to the start request to the management device, and the management device generates a common key unique to the session, which is used for the session, and transmits it to each in-vehicle device, communication using an individual common key can be performed for each session between the in-vehicle devices, so that the security of communication between the in-vehicle devices can be improved. Also, for example, by authenticating the in-vehicle device that is the source of the start request, a start request from an unauthorized device can be detected. Therefore, the security in the in-vehicle network can be further improved.

[0059] (20) When detecting an abnormality in the in-vehicle system while the in-vehicle device is transmitting information to the plurality of in-vehicle devices by multicast, the in-vehicle device may switch to a state of transmitting information to the plurality of in-vehicle devices by unicast.

[0060] With such a configuration, in the in-vehicle system, for example, when an abnormality such as intrusion by an unauthorized device occurs, it is possible to maintain a state in which secure communication is possible at least between legitimate in-vehicle devices.

[0061] (21) The management device includes a storage unit that stores the unique ID of each in-vehicle device in the in-vehicle system. The management device further transmits a hash value calculated using one of the unique IDs and the common key to the in-vehicle device having the unique ID used for calculating the hash value. The in-vehicle device may compare a hash value calculated using the common key received from the management device and its own unique ID with the hash value received from the management device.

[0062] With such a configuration, in the in-vehicle device, it is possible to confirm whether the common key received from the management device has been tampered with based on the comparison result between the calculated hash value and the hash value received from the management device.

[0063] (22) The communication management method according to an embodiment of the present disclosure is a communication management method in an in-vehicle relay device that performs relay processing for transmitting a plurality of frames received from a plurality of in-vehicle devices to the in-vehicle device of the destination, respectively. The method includes: determining whether the plurality of frames include a session start request for communication between the plurality of in-vehicle devices and a start response to the start request; generating a common key for each session used by the in-vehicle device that is the source of the frame determined to include the start request and one or more of the in-vehicle devices that are the sources of the frames determined to include the start response; and transmitting the generated common key to each in-vehicle device participating in the session.

[0064] In this way, in the in-vehicle relay device, it is determined whether the received frame includes a start request and whether the received frame includes a start response, and a common key used for a session in which the in-vehicle device that is the transmission source of the frame including the start request and one or more in-vehicle devices that are the transmission sources of the frames including the start response participate is generated for each session and transmitted to each in-vehicle device. By this method, communication using an individual common key can be performed for each session among in-vehicle devices, so the security of communication among in-vehicle devices can be improved. Also, for example, by authenticating the in-vehicle device that is the transmission source of the start request and the in-vehicle device that is the transmission source of the start response and then generating and transmitting the common key, participation in the session by unauthorized devices can be prevented. Therefore, the security in the in-vehicle network can be further improved.

[0065] (23) The communication management method according to an embodiment of the present disclosure is a communication management method in a management device used in an in-vehicle system including a plurality of in-vehicle devices, the method including: receiving, from a plurality of the in-vehicle devices, a start request for a session of communication between a part or all of the plurality of in-vehicle devices and a start response to the start request; generating a common key unique to the session, which is used for the session associated with the received start request and start response; and transmitting the generated common key to each of the in-vehicle devices participating in the session.

[0066] In this way, by receiving a start request and a start response for a session from in-vehicle devices, generating a common key unique to the session that is used for the session, and transmitting it to each in-vehicle device, communication using an individual common key can be performed for each session among in-vehicle devices, so the security of communication among in-vehicle devices can be improved. Also, for example, by authenticating the in-vehicle device that is the transmission source of the start request, a start request from an unauthorized device can be detected. Therefore, the security in the in-vehicle network can be further improved.

[0067] (24) The communication management method according to an embodiment of the present disclosure is a communication management method in a vehicle-mounted system including a plurality of vehicle-mounted devices including a first vehicle-mounted device and a second vehicle-mounted device, and a vehicle-mounted relay device that performs relay processing for transmitting a plurality of frames received from each of the plurality of vehicle-mounted devices to the vehicle-mounted device of the destination, wherein the first vehicle-mounted device transmits a first frame including a start request for a communication session between some or all of the plurality of vehicle-mounted devices to the vehicle-mounted relay device; the second vehicle-mounted device transmits a second frame including a start response to the start request to the vehicle-mounted relay device; and the vehicle-mounted relay device generates a common key for each session used in the session in which the first vehicle-mounted device that is the transmission source of the received first frame and the second vehicle-mounted device that is the transmission source of the received second frame participate, and transmits the generated common key to each vehicle-mounted device participating in the session.

[0068] In this way, by the method in which the first vehicle-mounted device transmits a start request to the vehicle-mounted relay device, the second vehicle-mounted device transmits a start response to the vehicle-mounted relay device, and the vehicle-mounted relay device generates a common key for each session used in the session in which the first vehicle-mounted device and the second vehicle-mounted device participate and transmits it to each vehicle-mounted device, communication can be performed using an individual common key for each session between the vehicle-mounted devices, so that the security of communication between the vehicle-mounted devices can be improved. Further, for example, by performing authentication of the vehicle-mounted device that is the transmission source of the start request and the vehicle-mounted device that is the transmission source of the start response and then generating and transmitting the common key, it is possible to prevent unauthorized devices from participating in the session. Therefore, the security in the vehicle-mounted network can be further improved.

[0069] (25) The communication management method according to an embodiment of the present disclosure is a communication management method in a vehicle-mounted system including a plurality of vehicle-mounted devices including a first vehicle-mounted device and a second vehicle-mounted device, and a management device, wherein the first vehicle-mounted device transmits a session start request for communication between a plurality of the vehicle-mounted devices that are some or all of the plurality of vehicle-mounted devices to the management device, the second vehicle-mounted device transmits a start response to the start request to the management device, and the management device generates a common key unique to the session to be used for the session associated with the received start request and start response, and transmits the generated common key to each vehicle-mounted device participating in the session.

[0070] In this way, by the method in which the first vehicle-mounted device transmits a session start request to the management device, the second vehicle-mounted device transmits a start response to the start request to the management device, and the management device generates a common key unique to the session to be used for the session and transmits it to each vehicle-mounted device, communication using an individual common key can be performed for each session between vehicle-mounted devices, so that the security of communication between vehicle-mounted devices can be improved. Also, for example, by authenticating the vehicle-mounted device that is the transmission source of the start request, a start request from an unauthorized device can be detected. Therefore, the security in the vehicle network can be further improved.

[0071] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals and their descriptions will not be repeated. Also, at least a part of the embodiments described below may be arbitrarily combined.

[0072] 〔First Embodiment〕 [Configuration and Basic Operation] <Vehicle-mounted System> FIG. 1 is a diagram showing the configuration of an in-vehicle system according to the first embodiment of the present disclosure. Referring to FIG. 1, the in-vehicle system 301 includes a relay device 101 and a plurality of in-vehicle ECUs 111. The relay device 101 is an example of an in-vehicle relay device. The in-vehicle ECU 111 is an example of an in-vehicle device. The in-vehicle system 301 is mounted on the vehicle 1. The relay device 101 is used in the in-vehicle system 301.

[0073] The relay device 101 is connected to each in-vehicle ECU 111 via the cable 14. For example, the relay device 101 and the in-vehicle ECU 111 are connected without passing through another relay device. The cable 14 is, for example, an Ethernet (registered trademark) cable. The relay device 101 and the in-vehicle ECU 111 constitute an in-vehicle network.

[0074] The in-vehicle ECU 111 is, for example, an electric power steering (EPS), a brake control device, an accelerator control device, a steering control device, a driving assistance device that gives instructions to various devices in an advanced driver-assistance system (ADAS), or a sensor or the like.

[0075] FIG. 2 is a diagram showing an example of an Ethernet frame transmitted and received in the in-vehicle system according to the first embodiment of the present disclosure. Referring to FIG. 2, the Ethernet frame has an Ethernet header, an IP (Internet Protocol) header, a TCP (Transmission Control Protocol) header, a data field, and an FCS (Frame Check Sequence). The Ethernet header stores a destination MAC (Media Access Control) address, a source MAC address, and a type.

[0076] The in-vehicle ECU 111 generates an Ethernet frame addressed to another in-vehicle ECU 111 and transmits the generated Ethernet frame to the relay device 101.

[0077] The relay device 101 can communicate with the in-vehicle ECU 111. The relay device 101 performs a relay process of transmitting the Ethernet frame received from the in-vehicle ECU 111 to another in-vehicle ECU 111. For example, the relay device 101 performs the relay process according to Layer 2. Note that the relay device 101 may be configured to perform the relay process according to Layer 3, which is higher than Layer 2.

[0078] (SOME / IP) In the in-vehicle system 301, for example, messages are transmitted and received according to SOME / IP (Scalable service-Oriented MiddlewarE over IP), which is a protocol of a layer above the session layer in the Internet protocol suite. More specifically, the in-vehicle ECU 111 stores a message containing various information in the data field of the Ethernet frame, and transmits the Ethernet frame to another in-vehicle ECU 111 via the relay device 101 according to SOME / IP.

[0079] For example, the in-vehicle ECU 111 starts a communication session among a plurality of in-vehicle ECUs 111. Then, the plurality of in-vehicle ECUs 111 participating in the session transmit and receive messages. The combination of the in-vehicle ECUs 111 participating in the session is not fixed and changes dynamically.

[0080] As an example, a sensor, which is an in-vehicle ECU 111, and a driving assistance device, which is another in-vehicle ECU 111, start a session. In this case, as a service, the sensor stores sensor information regarding the driving state or the surrounding state of the vehicle 1 in a message and transmits the message to the driving assistance device. The driving assistance device acquires the sensor information provided as a service from the received message, generates various control information regarding the driving of the vehicle 1 using the sensor information, and transmits the generated various control information to a brake control device, a steering control device, etc.

[0081] Hereinafter, the in-vehicle ECU 111 on the service-providing side is also referred to as a "server". Also, the in-vehicle ECU 111 on the service-receiving side is also referred to as a "client". The in-vehicle ECU 111 may function only as a server, may function only as a client, or may function as a server or a client according to the content of the service in the session. The server is an example of the first in-vehicle device. The client is an example of the second in-vehicle device.

[0082] (A) Start of session In communication conforming to SOME / IP, a session starts when Service Discovery is executed. More specifically, a plurality of in-vehicle ECUs 111 start a session by transmitting and receiving SOME / IP-SD messages.

[0083] FIG. 3 is a diagram showing an example of SOME / IP-SD messages transmitted and received in the in-vehicle system according to the first embodiment of the present disclosure. Referring to FIG. 3, the SOME / IP-SD message has a SOME / IP header and a SOME / IP-SD header.

[0084] (A-1) Offer message As an example, due to the function of Service Discovery, the server offers to provide a service, and a session between the client and the server starts.

[0085] For example, an in-vehicle ECU 111, acting as a server, multicasts an Offer message, which is an example of a SOME / IP-SD message, periodically or irregularly. More specifically, the server generates an Offer message in which a service ID corresponding to a service that the server can provide is stored in the SOME / IP-SD header. Then, the server generates an Ethernet frame in which the Offer message is stored in the data field and a multicast address is stored as the destination MAC address, and transmits the generated Ethernet frame to the relay device 101. The Offer message is an example of a session start request.

[0086] Among the plurality of in-vehicle ECUs 111 that have received the Offer message from the server via the relay device 101, the in-vehicle ECU 111 that requires the service corresponding to the service ID included in the Offer message, acting as a client, transmits a Subscribe message, which is an example of a SOME / IP-SD message, to the server via the relay device 101. More specifically, the client generates an Ethernet frame in which the Subscribe message is stored in the data field, and transmits the generated Ethernet frame to the server via the relay device 101. The Subscribe message is an example of a start response to a session start request.

[0087] When the server receives the Subscribe message from the client via the relay device 101, the server starts providing services to the client.

[0088] (A-2) Find message As another example, through the Service Discovery function, the client searches for a server that is the service provider, and a communication session between the client and the server is started.

[0089] For example, a certain in-vehicle ECU 111 multicasts, as a client, a Find message, which is an example of a SOME / IP-SD message, periodically or aperiodically. More specifically, the client generates a Find message in which a service ID corresponding to the service to be received is stored in the SOME / IP-SD header. Then, the client generates an Ethernet frame in which the Find message is stored in the data field and a multicast address is stored as the destination MAC address, and transmits the generated Ethernet frame to the relay device 101. The Find message is an example of a search request for a session.

[0090] Among the plurality of in-vehicle ECUs 111 that have received the Find message from the client via the relay device 101, the in-vehicle ECU 111 that can provide the service corresponding to the service ID included in the Find message transmits, as a server, an Offer message, which is an example of a SOME / IP-SD message, to the client via the relay device 101. More specifically, the server generates an Ethernet frame in which the Offer message is stored in the data field, and transmits the generated Ethernet frame to the client via the relay device 101. The Offer message is an example of a start request for a search request for a session.

[0091] When the client receives the Offer message from the server via the relay device 101, the client transmits a Subscribe message, which is an example of a SOME / IP-SD message, to the server via the relay device 101. More specifically, the client generates an Ethernet frame in which the Subscribe message is stored in the data field, and transmits the generated Ethernet frame to the server via the relay device 101. The Subscribe message is an example of a start response to a start request for a session.

[0092] When the server receives the Subscribe message from the client via the relay device 101, the server starts providing the service to the client.

[0093] (B) Communication in the session In communication according to SOME / IP, in the sessions of the server and the client, SOME / IP messages are sent from the server to the client.

[0094] FIG. 4 is a diagram showing an example of SOME / IP messages transmitted and received in the in-vehicle system according to the first embodiment of the present disclosure. Referring to FIG. 4, the SOME / IP message has a SOME / IP header and a payload.

[0095] For example, the server periodically or irregularly sends a session message, which is an example of a SOME / IP message, to the client via the relay device 101. More specifically, the server generates a session message in which the information to be provided as a service is stored in the payload. Then, the server generates an Ethernet frame in which the session message is stored in the data field, and transmits the generated Ethernet frame to the client via the relay device 101.

[0096] (C) End of session In communication according to SOME / IP, the session ends when Service Discovery is executed. More specifically, a plurality of in-vehicle ECUs 111 end the session by transmitting and receiving SOME / IP-SD messages.

[0097] (C-1) StopOffer message As an example, due to the function of Service Discovery, the server offers to stop providing the service, and the session ends.

[0098] For example, when the server stops providing a service, it sends a StopOffer message, which is an example of a SOME / IP-SD message, to the client. More specifically, the server generates a StopOffer message with the service ID corresponding to the service to be stopped stored in the SOME / IP-SD header. Then, the server generates an Ethernet frame with the StopOffer message stored in the data field and sends the generated Ethernet frame to the client via relay device 101. The StopOffer message is an example of a session termination request.

[0099] After the server sends the StopOffer message to the client via relay device 101, it terminates the service provision to the client.

[0100] (C-2) StopSubscribe message As another example, due to the Service Discovery function, the client requests to stop enjoying the service and the session ends.

[0101] For example, when the client stops enjoying a service, it sends a StopSubscribe message, which is an example of a SOME / IP-SD message, to the server. More specifically, the client generates a StopSubscribe message with the service ID corresponding to the service to be stopped stored in the SOME / IP-SD header. Then, the client generates an Ethernet frame with the StopSubscribe message stored in the data field and sends the generated Ethernet frame to the server via relay device 101. The StopSubscribe message is an example of a session termination request.

[0102] When the server receives the Stop Subscribe message from the client via relay device 101, it terminates the service provision to the client.

[0103] <Overview of Processing in In-Vehicle ECU and Relay Device> FIG. 5 is a diagram showing the configuration of an in-vehicle ECU according to the first embodiment of the present disclosure. Referring to FIG. 5, the in-vehicle ECU 111 includes a communication unit 11, a processing unit 12, and a storage unit 13. The communication unit 11 and the processing unit 12 are realized by a processor such as a CPU (Central Processing Unit) and a DSP (Digital Signal Processor), for example. The storage unit 13 is a non-volatile memory, for example.

[0104] The storage unit 13 in the in-vehicle ECU 111 stores the unique ID of the in-vehicle ECU 111, the ECU identifier which is an identifier of the in-vehicle ECU 111, the endpoint information of the in-vehicle ECU 111, and the endpoint information of the relay device 101. The unique ID is written into the storage unit 13, for example, when the vehicle 1 is shipped. The unique ID has a higher confidentiality than the ECU identifier. The endpoint information includes an IP address and a logical port number.

[0105] In addition, the storage unit 13 stores a service list indicating the correspondence between the content of the service provided in the in-vehicle system 301 and the service ID.

[0106] FIG. 6 is a diagram showing the configuration of the relay device according to the first embodiment of the present disclosure. Referring to FIG. 6, the relay device 101 includes a plurality of communication ports 21, a relay unit 22, a processing unit 23, a log generation unit 24, and a storage unit 25. The processing unit 23 is an example of a determination unit, an example of a generation unit, and an example of a transmission unit. The log generation unit 24 is an example of a recording unit. The relay unit 22, the processing unit 23, and the log generation unit 24 are realized by a processor such as a CPU and a DSP, for example. The storage unit 25 is a non-volatile memory, for example.

[0107] The communication port 21 is a terminal to which the cable 14 can be connected. The communication port 21 is connected to the in-vehicle ECU 111 via the cable 14. Note that the communication port 21 may be a terminal of an integrated circuit.

[0108] The storage unit 25 stores an address table Tb1 indicating the correspondence between the port number of the communication port 21 and the MAC address of the in-vehicle ECU 111 connected to the communication port 21.

[0109] In addition, the storage unit 25 stores the unique ID of each in-vehicle ECU 111 in the in-vehicle system 301. For example, the storage unit 25 stores a connection destination list indicating the endpoint information, ECU identifier, and unique ID of the servers and clients that can participate in the service for each service ID.

[0110] FIG. 7 is a diagram showing an example of a connection destination list stored in the storage unit in the relay device according to the first embodiment of the present disclosure. Referring to FIG. 7, in the connection destination list, endpoint information of two servers and two clients that can participate in a service with a service ID of "0x0001", and endpoint information of one server and two clients that can participate in a service with a service ID of "0x0002" are registered. Specifically, in the connection destination list, for example, as a server that can participate in a service with a service ID of "0x0002", an in-vehicle ECU 111 with endpoint information of "AAA", an ECU identifier of "ECU_1", and a unique ID of "ID_A" is registered. Here, the numbers starting with "0x" mean that the numbers after "0x" are represented in hexadecimal.

[0111] The relay unit 22 performs a relay process of transmitting a plurality of Ethernet frames received from a plurality of in-vehicle ECUs 111 to the destination in-vehicle ECU 111, respectively. As will be described later, the relay unit 22 may discard the received Ethernet frame without relaying it to the destination in-vehicle ECU 111 according to an instruction from the processing unit 23.

[0112] More specifically, when the relay unit 22 receives an Ethernet frame from a certain in-vehicle ECU 111 via the corresponding communication port 21, the relay unit 22 stores the received Ethernet frame in the storage unit 25.

[0113] The processing unit 23 determines whether the Ethernet frame received by the relay unit 22 contains a SOME / IP-SD message. For example, when the Ethernet frame is stored in the storage unit 25 by the relay unit 22, the processing unit 23 checks whether the SOME / IP-SD header is included in the data field of the Ethernet frame.

[0114] If the SOME / IP-SD header is not included in the data field of the Ethernet frame stored in the storage unit 25 by the relay unit 22, the processing unit 23 determines that the Ethernet frame does not contain a SOME / IP-SD message, and outputs a relay instruction indicating that the relay processing of the Ethernet frame should be performed to the relay unit 22.

[0115] When receiving the relay instruction from the processing unit 23, the relay unit 22 acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs the relay processing of the Ethernet frame. Specifically, the relay unit 22 refers to the address table Tb1 in the storage unit 25, and transmits the Ethernet frame to the destination in-vehicle ECU 111 via the communication port 21 of the port number corresponding to the destination MAC address of the Ethernet frame.

[0116] On the one hand, when the data field of the Ethernet frame stored in the storage unit 25 by the relay unit 22 contains a SOME / IP-SD header, the processing unit 23 determines that the Ethernet frame contains a SOME / IP-SD message. Then, by referring to the SOME / IP-SD header, the processing unit 23 determines that the Ethernet frame contains an Offer message. Alternatively, by referring to the SOME / IP-SD header of the Ethernet frame stored in the storage unit 25 by the relay unit 22, the processing unit 23 determines that the Ethernet frame contains a Find message. Alternatively, by referring to the SOME / IP-SD header of the Ethernet frame stored in the storage unit 25 by the relay unit 22, the processing unit 23 determines that the Ethernet frame contains a Subscribe message. Alternatively, by referring to the SOME / IP-SD header of the Ethernet frame stored in the storage unit 25 by the relay unit 22, the processing unit 23 determines that the Ethernet frame contains a StopOffer message. Alternatively, by referring to the SOME / IP-SD header of the Ethernet frame stored in the storage unit 25 by the relay unit 22, the processing unit 23 determines that the Ethernet frame contains a StopSubscribe message.

[0117] In addition, when the processing unit 23 determines that the Ethernet frame stored in the storage unit 25 by the relay unit 22 contains a SOME / IP-SD message, the processing unit 23 determines the suitability of the Ethernet frame.

[0118] According to the determination result of the suitability of the Ethernet frame by the processing unit 23, the relay unit 22 performs relay processing or discards the Ethernet frame.

[0119] More specifically, when the processing unit 23 determines that the Ethernet frame is inappropriate, the processing unit 23 outputs a discard instruction indicating that the Ethernet frame should be discarded to the relay unit 22.

[0120] When the relay unit 22 receives a discard instruction from the processing unit 23, it discards the Ethernet frame indicated by the relay instruction in the storage unit 25.

[0121] On the other hand, when the processing unit 23 determines that the Ethernet frame is appropriate, it outputs a relay instruction indicating that the relay processing of the Ethernet frame should be performed to the relay unit 22.

[0122] When the relay unit 22 receives a relay instruction from the processing unit 23, it acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs relay processing on the Ethernet frame.

[0123] The processing unit 23 generates a session key K for each session used by the in-vehicle ECU 111 that is the source of the Ethernet frame determined to include a start request such as an Offer message and one or more in-vehicle ECUs 111 that are the sources of the Ethernet frames determined to include a start response such as a Subscribe message. The session key K is an example of a common key and is, for example, a random number with a key length according to the encryption method used. For example, the processing unit 23 generates a session key K with random content for each session.

[0124] The processing unit 23 transmits the generated session key K to each in-vehicle ECU 111 participating in the session via the relay unit 22. The log generation unit 24 records session information regarding the session in which the session key K generated by the processing unit 23 is used.

[0125] (1) Example of processing in Service Discovery 1 (1-1) Transmission of Offer message by server Referring again to FIG. 5, in in-vehicle ECU 111 which is a server, processing unit 12 refers to the service list in storage unit 13 and acquires a service ID corresponding to a service that can be provided by the in-vehicle ECU 111. Further, processing unit 12 acquires an ECU identifier and endpoint information of the in-vehicle ECU 111 from storage unit 13. Processing unit 12 generates an Offer message including the acquired service ID, ECU identifier, and endpoint information.

[0126] Processing unit 12 calculates a MAC (Message Authentication Code) value based on the generated Offer message and the unique ID in storage unit 13. Processing unit 12 generates an Ethernet frame in which the Offer message and the MAC value are stored in a data field and a multicast address is stored as a destination MAC address. Processing unit 12 outputs the generated Ethernet frame to communication unit 11.

[0127] Communication unit 11 transmits the Ethernet frame received from processing unit 12 to relay device 101.

[0128] (1-2) Judgment of Appropriateness of Offer Message by Relay Device Referring again to FIG. 6, in relay device 101, relay unit 22 receives an Ethernet frame via a corresponding communication port from the server, attaches a timestamp to the received Ethernet frame, and stores the Ethernet frame in storage unit 25.

[0129] When the Ethernet frame is stored in storage unit 25 by relay unit 22, processing unit 23 confirms that an SOME / IP-SD header is included in the data field of the Ethernet frame, and by referring to the SOME / IP-SD header, determines that the Ethernet frame includes an Offer message. Then, processing unit 23 determines the appropriateness of the Ethernet frame.

[0130] More specifically, the processing unit 23 acquires an Offer message, a MAC value, and a timestamp from the Ethernet frame. Further, the processing unit 23 acquires a service ID, endpoint information of the in-vehicle ECU 111, and an ECU identifier from the acquired Offer message. Then, the processing unit 23 refers to the connection destination list in the storage unit 25, and checks whether the in-vehicle ECU 111 specified by the endpoint information and the ECU identifier acquired from the Offer message is registered in the connection destination list as a server that can participate in the service indicated by the service ID acquired from the Offer message.

[0131] As an example, when the service ID, endpoint information, and ECU identifier acquired from the Offer message are "0x0001", "BBB", and "ECU_2", respectively, the processing unit 23 determines that the in-vehicle ECU 111 specified by the ECU identifier and the endpoint information is registered in the connection destination list as a server that can participate in the service indicated by the service ID.

[0132] In addition, the processing unit 23 refers to the connection destination list and acquires the unique ID of the in-vehicle ECU 111 specified by the endpoint information etc. acquired from the Offer message. The processing unit 23 calculates a MAC value based on the Offer message and the acquired unique ID. Then, the processing unit 23 determines whether the Ethernet frame has been tampered with by comparing the MAC value acquired from the Ethernet frame with the MAC value calculated by itself.

[0133] When the in-vehicle ECU 111 identified by the endpoint information and the like obtained from the Offer message is registered in the connection destination list and the processing unit 23 determines that the Ethernet frame has not been tampered with, the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is appropriate. On the other hand, when the in-vehicle ECU 111 identified by the endpoint information and the like obtained from the Offer message is not registered in the connection destination list, or when the processing unit 23 determines that the Ethernet frame has been tampered with, the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate.

[0134] When the processing unit 23 determines that the Ethernet frame is appropriate, the ECU identifier and endpoint information obtained from the Offer message are stored in the storage unit 25 as server information.

[0135] Also, when the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is appropriate, the ECU identifier and endpoint information from the Offer message included in the Ethernet frame in the storage unit 25 are erased. Then, the processing unit 23 outputs a relay instruction indicating that the relay processing of the Ethernet frame should be performed to the relay unit 22.

[0136] When the relay unit 22 receives a relay instruction from the processing unit 23, the relay unit 22 acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs the relay processing of the Ethernet frame. Specifically, the relay unit 22 transmits the Ethernet frame from which the ECU identifier and endpoint information have been erased by the processing unit 23 to the in-vehicle ECU 111 other than the in-vehicle ECU 111 that is the transmission source of the Ethernet frame according to the multicast address that is the destination MAC address of the Ethernet frame.

[0137] On the other hand, when the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, the processing unit 23 outputs a discard instruction indicating that the Ethernet frame should be discarded to the relay unit 22.

[0138] When the relay unit 22 receives a discard instruction from the processing unit 23, it discards the Ethernet frame indicated by the discard instruction.

[0139] Also, when the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs an Offer message and a timestamp to the log generation unit 24. The log generation unit 24 records information regarding the message included in the Ethernet frame determined to be inappropriate by the processing unit 23.

[0140] FIG. 8 is a diagram showing an example of an illegal log list in the storage unit of the relay device according to the first embodiment of the present disclosure. Referring to FIG. 8, the storage unit 25 stores an illegal log list R1 that is a list of illegal logs indicating the byte sequence of the message included in the Ethernet frame determined to be inappropriate by the processing unit 23, the ECU identifier of the in-vehicle ECU 111 that is the transmission source of the Ethernet frame, and the reception time of the Ethernet frame.

[0141] Upon receiving an Offer message and a timestamp from the processing unit 23, the log generation unit 24 acquires the ECU identifier included in the received Offer message, and writes the byte sequence of the Offer message, the acquired ECU identifier, and the reception time as an illegal log to the illegal log list R1 in the storage unit 25.

[0142] (1-3) Transmission of Subscribe Message by Client Referring to FIG. 5 again, in the in-vehicle ECU 111 which is a client, the processing unit 12 receives an Ethernet frame from the relay device 101 via the communication unit 11, and acquires the transmission source MAC address and the Offer message from the received Ethernet frame. Also, the processing unit 12 acquires the service ID from the acquired Offer message.

[0143] The processing unit 12 refers to the service list in the storage unit 13 and determines the necessity of the service indicated by the acquired service ID. When the processing unit 12 determines that the service is necessary, it acquires the ECU identifier and the endpoint information of the in-vehicle ECU 111 from the storage unit 13, and generates a Subscribe message including the service ID corresponding to the service, the acquired ECU identifier, and the acquired endpoint information. On the other hand, when the processing unit 12 determines that the service is unnecessary, it does not generate a Subscribe message.

[0144] The processing unit 12 calculates a MAC value based on the generated Subscribe message and the unique ID in the storage unit 13. The processing unit 12 generates an Ethernet frame in which the Subscribe message and the MAC value are stored in the data field and the MAC address of the server is stored as the destination MAC address. The processing unit 12 outputs the generated Ethernet frame to the communication unit 11.

[0145] The communication unit 11 transmits the Ethernet frame received from the processing unit 12 to the relay device 101.

[0146] (1-4) Judgment of the suitability of the Subscribe message by the relay device Referring to FIG. 6 again, the relay unit 22 in the relay device 101 receives an Ethernet frame via the corresponding communication port from the client, attaches a timestamp to the received Ethernet frame, and stores the Ethernet frame in the storage unit 25.

[0147] When the Ethernet frame is stored in the storage unit 25 by the relay unit 22, the processing unit 23 confirms that the SOME / IP-SD header is included in the data field of the Ethernet frame, and by referring to the SOME / IP-SD header, determines that the Ethernet frame includes a Subscribe message. Then, the processing unit 23 determines the suitability of the Ethernet frame.

[0148] More specifically, the processing unit 23 acquires a Subscribe message, a MAC value, and a timestamp from the Ethernet frame. Further, the processing unit 23 acquires a service ID, endpoint information of the in-vehicle ECU 111, and an ECU identifier from the acquired Subscribe message. Then, the processing unit 23 refers to the connection destination list in the storage unit 25, and checks whether the in-vehicle ECU 111 specified by the endpoint information and the ECU identifier acquired from the Subscribe message is registered in the connection destination list as a client that can participate in the service indicated by the service ID acquired from the Subscribe message.

[0149] As an example, when the service ID, endpoint information, and ECU identifier acquired from the Subscribe message are "0x0001", "CCC", and "ECU_3", respectively, the processing unit 23 determines that the in-vehicle ECU 111 specified by the ECU identifier and the endpoint information is registered in the connection destination list as a client that can participate in the service indicated by the service ID.

[0150] In addition, the processing unit 23 refers to the connection destination list and acquires the unique ID of the in-vehicle ECU 111 specified by the endpoint information etc. acquired from the Subscribe message. The processing unit 23 calculates a MAC value based on the Subscribe message and the acquired unique ID. Then, the processing unit 23 determines whether the Ethernet frame has been tampered with by comparing the MAC value acquired from the Ethernet frame with the MAC value calculated by itself.

[0151] When the in-vehicle ECU 111 identified by the endpoint information etc. obtained from the Subscribe message is registered in the connection destination list and it is determined that the Ethernet frame has not been tampered with, the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is appropriate. On the other hand, when the in-vehicle ECU 111 identified by the endpoint information etc. obtained from the Subscribe message is not registered in the connection destination list, or when it is determined that the Ethernet frame has been tampered with, the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate.

[0152] When the processing unit 23 determines that the Ethernet frame is appropriate, it stores the ECU identifier and the endpoint information obtained from the Subscribe message in the storage unit 25 as client information.

[0153] On the other hand, when the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs a discard instruction indicating that the Ethernet frame should be discarded to the relay unit 22.

[0154] When the relay unit 22 receives a discard instruction from the processing unit 23, it discards the Ethernet frame indicated by the discard instruction.

[0155] Also, when the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs the Subscribe message and the timestamp to the log generation unit 24. The log generation unit 24 writes information about the message included in the Ethernet frame determined to be inappropriate by the processing unit 23 to the unauthorized log list R1 in the storage unit 25.

[0156] (1-5) Generation and distribution of session keys by the relay device When the processing unit 23 in the relay device 101 determines that the Ethernet frame storing the Subscribe message is appropriate and stores the client information in the storage unit 25, it decides to establish a session between the server and the client indicated by the server information and the client information stored in the storage unit 25, respectively.

[0157] Then, the processing unit 23 generates a session key K to be used for the session and a key ID which is the ID of the session key K, and distributes the generated session key K and key ID to the server and the client participating in the session. Further, the processing unit 23 stores the generated session key K and key ID in the storage unit 25 in association with the service ID.

[0158] For example, the processing unit 23 encrypts the session key K using the unique ID as an encryption key. Also, for example, the processing unit 23 calculates a hash value HV using the unique ID and the session key K. Then, the processing unit 23 transmits the encrypted session key K and the hash value HV to the in-vehicle ECU 111 having the unique ID used for the encryption of the session key K and the calculation of the hash value HV via the relay unit 22.

[0159] More specifically, the processing unit 23 refers to the destination list in the storage unit 25, obtains the unique ID of the server indicated by the server information, and encrypts the session key K using the obtained unique ID as an encryption key, thereby generating an encrypted key KS which is the encrypted session key K for the server. Then, the processing unit 23 includes the encrypted key KS and the corresponding key ID in the Subscribe message included in the Ethernet frame in the storage unit 25, and gives the Subscribe message and the unique ID of the server to a predetermined hash function to calculate a hash value HVS. The processing unit 23 further stores the calculated hash value HVS in the Ethernet frame. Then, the processing unit 23 outputs a relay instruction indicating that the relay processing of the Ethernet frame should be performed to the relay unit 22.

[0160] When the relay unit 22 receives a relay instruction from the processing unit 23, it acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs relay processing on the Ethernet frame. Specifically, the relay unit 22 transmits an Ethernet frame in which the encryption key KS, the key ID, and the hash value HVS are stored to the server according to the destination MAC address of the Ethernet frame.

[0161] Also, the processing unit 23 refers to the destination list in the storage unit 25, acquires the unique ID of the client indicated by the client information, and encrypts the session key K using the acquired unique ID as an encryption key, thereby generating an encryption key KC, which is the encrypted session key K for the client. Then, the processing unit 23 generates a start message MC including the server endpoint information, the encryption key KC, and the corresponding key ID, and calculates a hash value HVC by applying the generated start message MC and the acquired unique ID to a predetermined hash function. The processing unit 23 generates an Ethernet frame for the client including the generated start message MC and the calculated hash value HVC, and transmits the generated Ethernet frame to the client via the relay unit 22.

[0162] The processing unit 23 outputs session information indicating the service ID of the service provided in the session to be established, the ECU identifier of the server that is the destination of the Subscribe message, the ECU identifier of the client that is the destination of the start message MC, and the output time ts of the Subscribe message and the start message MC to the log generation unit 24. The output time ts indicates the transmission time of the session key K by the relay unit 22.

[0163] FIG. 9 is a diagram showing an example of a session log list in a storage unit in the relay device according to the first embodiment of the present disclosure. Referring to FIG. 9, the storage unit 25 stores a session log list R2, which is a list of session logs indicating the service ID of the service provided in the established session, the ECU identifiers of the server and the client that are the distribution destinations of the session key K, the start time of the session, and the end time of the session.

[0164] The log generation unit 24 receives session information from the processing unit 23 and writes the service ID, ECU identifier, and output time ts included in the received session information to the session log list R2 as the "service ID", "ECU identifier", and "start time" of the session log, respectively.

[0165] (1-6) Reception of Session Key by Server Referring to FIG. 5 again, in the server, the processing unit 12 receives an Ethernet frame from the relay device 101 via the communication unit 11, and acquires a Subscribe message and a hash value HVS from the received Ethernet frame. The processing unit 12 collates the hash value calculated using the session key K received from the relay device 101 and its own unique ID with the hash value HVS received from the relay device 101.

[0166] More specifically, the processing unit 12 acquires the unique ID from the storage unit 13, and calculates a hash value by providing the Subscribe message and the unique ID to a predetermined hash function. The processing unit 12 determines whether the Subscribe message has been tampered with by collating the hash value HVS with the hash value calculated by itself.

[0167] When the processing unit 12 determines that the Subscribe message has been tampered with, it discards the Subscribe message. On the other hand, when the processing unit 12 determines that the Subscribe message has not been tampered with, it obtains the client's endpoint information, encryption key KS, and key ID from the Subscribe message. Then, the processing unit 12 obtains the session key K by decrypting the encryption key KS using the unique ID.

[0168] When the key ID of the session key K acquired in the past is stored in the storage unit 13, the processing unit 12 compares the key ID in the storage unit 13 with the newly acquired key ID. When the processing unit 12 confirms that the key ID in the storage unit 13 is different from the newly acquired key ID, it stores the newly acquired client endpoint information, session key K, and key ID in the storage unit 13.

[0169] On the other hand, when the key ID in the storage unit 13 matches the newly acquired key ID, the processing unit 12 transmits a message requesting retransmission of the session key K to the relay device 101 via the communication unit 11. When the relay device 101 receives the message, it generates a new session key K and transmits it to the server and the client. As a result, when the same session key K used in a past session is distributed to the server and the client, the relay device 101 can be prompted to regenerate the session key K, thus avoiding a decrease in security due to the use of the same session key K in different sessions.

[0170] (1-7) Reception of Session Key by Client In the client, the processing unit 12 receives an Ethernet frame from the relay device 101 via the communication unit 11, and obtains the start message MC and the hash value HVC from the received Ethernet frame. The processing unit 12 collates the hash value calculated using the session key K received from the relay device 101 and its own unique ID with the hash value HVC received from the relay device 101.

[0171] More specifically, the processing unit 12 acquires the unique ID from the storage unit 13, and calculates a hash value by applying the start message MC and the unique ID to a predetermined hash function. The processing unit 12 determines whether the start message MC has been tampered with by comparing the hash value HVC with the hash value calculated by itself.

[0172] If the processing unit 12 determines that the start message MC has been tampered with, it discards the start message MC. On the other hand, if the processing unit 12 determines that the start message MC has not been tampered with, it acquires the server endpoint information, the encryption key KC, and the key ID from the start message MC. Then, the processing unit 12 acquires the session key K by decrypting the encryption key KC using the unique ID.

[0173] If the key ID of the session key K acquired in the past is stored in the storage unit 13, the processing unit 12 compares the key ID in the storage unit 13 with the newly acquired key ID. When the processing unit 12 confirms that the key ID in the storage unit 13 is different from the newly acquired key ID, it stores the newly acquired server endpoint information, session key K, and key ID in the storage unit 13.

[0174] On the other hand, if the key ID in the storage unit 13 matches the newly acquired key ID, the processing unit 12 transmits a message requesting retransmission of the session key K to the relay device 101 via the communication unit 11. When the relay device 101 receives the message, it generates a new session key K and transmits it to the server and the client.

[0175] Here, since the number of different session keys K that can be generated in the relay device 101 is finite, the relay device 101 may distribute the same session key K as a certain session key K after a sufficient time has passed after the distribution of the certain session key K. Therefore, the processing unit 12 in the server and the client deletes the key ID from the storage unit 13 after a sufficient time has passed since the key ID was stored in the storage unit 13.

[0176] (2) Processing Example 2 in Service Discovery (2-1) Transmission of Find Message by Client In in-vehicle ECU 111 which is a client, processing unit 12 refers to the service list in storage unit 13 and acquires the service ID corresponding to the service for which provision is to be received. Further, processing unit 12 acquires the ECU identifier and the endpoint information of the in-vehicle ECU 111 from storage unit 13. Processing unit 12 generates a Find message including the acquired service ID, ECU identifier, and endpoint information.

[0177] Processing unit 12 calculates a MAC value based on the generated Find message and the unique ID in storage unit 13. Processing unit 12 generates an Ethernet frame in which the Find message and the MAC value are stored in the data field and a multicast address is stored as the destination MAC address. Processing unit 12 outputs the generated Ethernet frame to communication unit 11.

[0178] Communication unit 11 transmits the Ethernet frame received from processing unit 12 to relay device 101.

[0179] (2-2) Judgment on Appropriateness of Find Message by Relay Device Referring to FIG. 6 again, relay unit 22 in relay device 101 receives an Ethernet frame via the corresponding communication port from the server, attaches a timestamp to the received Ethernet frame, and stores the Ethernet frame in storage unit 25.

[0180] When the Ethernet frame is stored in storage unit 25 by relay unit 22, processing unit 23 confirms that the data field of the Ethernet frame contains an SOME / IP-SD header, and by referring to the SOME / IP-SD header, determines that the Ethernet frame includes a Find message. Then, processing unit 23 determines the appropriateness of the Ethernet frame.

[0181] More specifically, the processing unit 23 acquires a Find message, a MAC value, and a timestamp from the Ethernet frame. Further, the processing unit 23 acquires a service ID, endpoint information of the in-vehicle ECU 111, and an ECU identifier from the acquired Find message. Then, the processing unit 23 refers to the connection destination list in the storage unit 25, and checks whether the in-vehicle ECU 111 specified by the endpoint information and the ECU identifier acquired from the Find message is registered in the connection destination list as a client that can participate in the service indicated by the service ID acquired from the Find message.

[0182]

[0183]

[0184] As an example, when the service ID, endpoint information, and ECU identifier acquired from the Find message are "0x0001", "CCC", and "ECU_3", respectively, the processing unit 23 determines that the in-vehicle ECU 111 specified by the ECU identifier and the endpoint information is registered in the connection destination list as a client that can participate in the service indicated by the service ID. Also, the processing unit 23 refers to the connection destination list and acquires the unique ID of the in-vehicle ECU 111 specified by the endpoint information etc. acquired from the Find message. The processing unit 23 calculates a MAC value based on the Find message and the acquired unique ID. Then, the processing unit 23 determines whether the Ethernet frame has been tampered with by comparing the MAC value acquired from the Ethernet frame with the MAC value calculated by itself.When the in-vehicle ECU 111 identified by the endpoint information and the like obtained from the Find message is registered in the connection destination list and it is determined that the Ethernet frame has not been tampered with, the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is appropriate. On the other hand, when the in-vehicle ECU 111 identified by the endpoint information and the like obtained from the Find message is not registered in the connection destination list, or when it is determined that the Ethernet frame has been tampered with, the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate.

[0185] When the processing unit 23 determines that the Ethernet frame is appropriate, it stores the ECU identifier and the endpoint information obtained from the Find message in the storage unit 25 as client information.

[0186] Also, when the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is appropriate, it erases the ECU identifier and the endpoint information from the Find message included in the Ethernet frame in the storage unit 25. Then, the processing unit 23 outputs a relay instruction indicating that the relay processing of the Ethernet frame should be performed to the relay unit 22.

[0187] When the relay unit 22 receives a relay instruction from the processing unit 23, it acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs the relay processing of the Ethernet frame.

[0188] On the other hand, when the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs a discard instruction indicating that the Ethernet frame should be discarded to the relay unit 22.

[0189] When the relay unit 22 receives a discard instruction from the processing unit 23, it discards the Ethernet frame indicated by the discard instruction.

[0190] Further, when the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, the processing unit 23 outputs a Find message and a timestamp to the log generation unit 24.

[0191] Upon receiving the Find message and the timestamp from the processing unit 23, the log generation unit 24 acquires the ECU identifier included in the received Find message, and writes the byte sequence of the Find message, the acquired ECU identifier, and the reception time into the unauthorized log list R1 in the storage unit 25 as an unauthorized log.

[0192] (2-3) Transmission of Offer Message by Server Referring to FIG. 5 again, in in-vehicle ECU 111 which is a server, the processing unit 12 receives an Ethernet frame from the relay device 101 via the communication unit 11, and acquires the source MAC address and the Find message from the received Ethernet frame. Further, the processing unit 12 acquires the service ID from the acquired Find message.

[0193] The processing unit 12 refers to the service list in the storage unit 13, and determines whether the service indicated by the acquired service ID can be provided. When the processing unit 12 determines that the service can be provided, the processing unit 12 acquires the ECU identifier and the endpoint information of the in-vehicle ECU 111 from the storage unit 13, and generates an Offer message including the service ID corresponding to the service, the acquired ECU identifier, and the acquired endpoint information. On the other hand, when the processing unit 12 determines that the service cannot be provided, the processing unit 12 does not generate an Offer message.

[0194] The processing unit 12 calculates a MAC value based on the generated Offer message and the unique ID in the storage unit 13. The processing unit 12 generates an Ethernet frame in which the Offer message and the MAC value are stored in the data field, and the MAC address of the client that is the source of the Find message is stored as the destination MAC address. The processing unit 12 outputs the generated Ethernet frame to the communication unit 11.

[0195] The communication unit 11 transmits the Ethernet frame received from the processing unit 12 to the relay device 101.

[0196] (2-4) Judgment on the suitability of the Offer message by the relay device Referring to FIG. 6 again, the relay unit 22 in the relay device 101 receives an Ethernet frame from the server via the corresponding communication port, attaches a timestamp to the received Ethernet frame, and stores the Ethernet frame in the storage unit 25.

[0197] The processing unit 23 determines the suitability of the Ethernet frame received by the relay unit 22 in the same manner as described in the above-mentioned "(1-2) Judgment on the suitability of the Offer message by the relay device". Then, when the processing unit 23 determines that the Ethernet frame is appropriate, it saves the server information to the storage unit 25 and outputs a relay instruction to the relay unit 22.

[0198] When the relay unit 22 receives a relay instruction from the processing unit 23, it acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs relay processing on the Ethernet frame.

[0199] (2-5) Transmission of the Subscribe message by the client Referring to FIG. 5 again, in the in-vehicle ECU 111 which is a client, the processing unit 12 generates an Ethernet frame in which a Subscribe message and a MAC value are stored in the data field, and the MAC address of the server that is the source of the Offer message is stored as the destination MAC address, in the same manner as described in the above-mentioned "(1-3) Transmission of the Subscribe message by the client", and transmits the generated Ethernet frame to the relay device 101 via the communication unit 11.

[0200] (2-6) Judgment on the suitability of the Subscribe message by the relay device Referring again to FIG. 6, the relay unit 22 in the relay device 101 receives an Ethernet frame from the client via the corresponding communication port, attaches a timestamp to the received Ethernet frame, and stores the Ethernet frame in the storage unit 25.

[0201] The processing unit 23 determines the propriety of the Ethernet frame received by the relay unit 22 in the same manner as in the above-described “(1-4) Determination of the propriety of the Subscribe message by the relay device”. Then, when the processing unit 23 determines that the Ethernet frame is appropriate, it stores the ECU identifier and the endpoint information obtained from the Subscribe message in the storage unit 25 as client information.

[0202] (2-7) Generation and distribution of the session key by the relay device The processing unit 23 in the relay device 101 determines to establish a session between the server and the client in the same manner as in the above-described “(1-5) Generation and distribution of the session key by the relay device”, generates a session key K used for the session and a key ID which is the ID of the session key K, and distributes the generated session key K and key ID to the server and the client participating in the session.

[0203] (2-8) Reception of the session key by the server and the client Referring again to FIG. 5, in the server, the processing unit 12 collates the hash value calculated using the session key K received from the relay device 101 and its own unique ID with the hash value HVS received from the relay device 101 in the same manner as in the above-described “(1-6) Reception of the session key by the server”.

[0204] Also, in the client, the processing unit 12 collates the hash value calculated using the session key K received from the relay device 101 and its own unique ID with the hash value HVC received from the relay device 101 in the same manner as in the above-described “(1-7) Reception of the session key by the client”.

[0205] (Communication in the session) When the server and the client acquire the session key K, they start a communication session using the session key K.

[0206] Specifically, in the server, the processing unit 12 encrypts the session message storing the information to be provided as a service using the session key K in the storage unit 13, and includes the encrypted session message in an Ethernet frame and transmits it to the client via the communication unit 11 and the relay device 101.

[0207] Also, in the client, the processing unit 12 acquires the session message from the Ethernet frame received from the server via the relay device 101 and the communication unit 11, decrypts the acquired session message using the session key K in the storage unit 13, and acquires information from the decrypted session message.

[0208] (Participation in an existing session) For example, even after the start of a session between a certain client and the server, the processing unit 12 in the server periodically or irregularly multicasts an Offer message.

[0209] More specifically, after the establishment of a session between the server S1 and the client C1, when the processing unit 23 in the relay device 101 receives an Ethernet frame storing a Subscribe message from another client C2 by the relay unit 22 and determines that the Ethernet frame is appropriate, it decides to establish a session between the server S1 and the client C2. That is, the processing unit 23 decides to establish a session between the server S1 and the client C2, for example, after distributing the session key K1 to the server S1 and the client C1.

[0210] In this case, for example, the processing unit 23 generates a session key K2 different from the session key K1 distributed to the server S1 and the client C1 as the session key K used for the session between the server S1 and the client C2, and distributes the generated session key K2 to the server S1 and the client C2.

[0211] That is, the processing unit 23 generates and distributes different session keys K for each combination of server and client.

[0212] (Multicast from server to client) In the in-vehicle system 301, the server is not limited to a configuration that unicasts session messages to the client. The server may be configured to multicast session messages to a plurality of clients.

[0213] For example, the processing unit 23 in the relay device 101 generates a session key K for each session in which the in-vehicle ECU 111 that is the source of the Ethernet frame determined to include a start request such as an Offer message and a plurality of in-vehicle ECUs 111 that are the sources of the Ethernet frames determined to include a start response such as a Subscribe message participate. More specifically, when the number of clients communicating in a session with one server reaches a predetermined number, the processing unit 23 generates a session key KM that is the session key K used for the session between the server and the plurality of clients, and distributes the generated session key KM to the server and the plurality of clients.

[0214] That is, for example, when the processing unit 23 determines to establish a session between the server S1 and the client C3 while two sessions between the server S1 and the clients C1 and C2 are respectively established, the processing unit 23 generates a session key K3 to be used for the session between the server S1 and the client C3 and distributes it to the server S1 and the client C3. Further, the processing unit 23 further generates a session key KM to be used for the sessions between the server S1 and the clients C1, C2, and C3, and a multicast address based on the endpoint information of the server S1 and the clients C1, C2, and C3, and distributes the generated session key KM and the multicast address to the server S1 and the clients C1, C2, and C3.

[0215] When the server S1 and the clients C1, C2, and C3 acquire the session key KM and the multicast address, they start a communication session using the session key KM and the multicast address.

[0216] FIG. 10 is a diagram showing an example of a session between a server and clients in an in-vehicle system according to the first embodiment of the present disclosure. Referring to FIG. 10, the server S1 has a session key K1 to be used for a session with the client C1, a session key K2 to be used for a session with the client C2, a session key K3 to be used for a session with the client C3, and a session key KM to be used for a session with the clients C1, C2, and C3. The client C1 has the session keys K1 and KM. The client C2 has the session keys K2 and KM. The client C3 has the session keys K3 and KM.

[0217] In the server S1, the processing unit 12 encrypts a session message storing information to be provided as a service using the session key KM, includes the encrypted session message in an Ethernet frame, and multicasts it to the clients C1, C2, and C3.

[0218] For example, when the in-vehicle system 301 detects an abnormality while the server S1 is transmitting information to the clients C1, C2, and C3 by multicast, it switches to a state of transmitting information to the plurality of clients C1, C2, and C3 by unicast.

[0219] As an example, consider a case where an unauthorized device that has hijacked the client C1 impersonates the server S1 and multicasts a session message encrypted using the session key KM to the server S1 and the clients C2 and C3, included in an Ethernet frame.

[0220] When the processing unit 12 in the server S1 receives the session message from the unauthorized device via the communication unit 11, since it has received the session message even though it is the sender of the session message, it determines that an abnormality has occurred in the in-vehicle system 301.

[0221] In this case, the processing unit 12 in the server S1 switches the transmission of the session message from multicast to unicast. Specifically, the processing unit 12 unicasts the session message encrypted using the session key K1 to the client C1 via the communication unit 11, unicasts the session message encrypted using the session key K2 to the client C2 via the communication unit 11, and unicasts the session message encrypted using the session key K3 to the client C3 via the communication unit 11.

[0222] (3) Processing Example 3 in Service Discovery (3-1) Transmission of StopSubscribe Message by Client Referring to FIG. 5 again, in the client, when the processing unit 12 stops enjoying the service, it generates a StopSubscribe message including the service ID, ECU identifier, and endpoint information corresponding to the service.

[0223] The processing unit 12 calculates a MAC value based on the generated StopSubscribe message and the unique ID in the storage unit 13. Also, the processing unit 12 encrypts the StopSubscribe message using the session key K in the storage unit 13. Then, the processing unit 12 generates an Ethernet frame in which the encrypted StopSubscribe message and the MAC value are stored in the data field, and the MAC address of the server is stored as the destination MAC address, and transmits the generated Ethernet frame to the relay device 101 via the communication unit 11.

[0224] Also, the processing unit 12 discards the session key K and the server endpoint information in the storage unit 13.

[0225] (3-2) Judgment of the validity of the StopSubscribe message by the relay device Referring again to FIG. 6, the relay unit 22 in the relay device 101 receives an Ethernet frame from the client via the corresponding communication port, attaches a timestamp to the received Ethernet frame, and stores the Ethernet frame in the storage unit 25.

[0226] When the Ethernet frame is stored in the storage unit 25 by the relay unit 22, the processing unit 23 confirms that the SOME / IP-SD header is included in the data field of the Ethernet frame, and by referring to the SOME / IP-SD header, determines that the Ethernet frame includes a StopSubscribe message. Then, the processing unit 23 determines the validity of the Ethernet frame.

[0227] More specifically, the processing unit 23 acquires a StopSubscribe message, a MAC value, and a timestamp from the Ethernet frame. Further, the processing unit 23 acquires a service ID, endpoint information of the in-vehicle ECU 111, and an ECU identifier from the acquired StopSubscribe message. Then, the processing unit 23 refers to the connection destination list in the storage unit 25, and checks whether the in-vehicle ECU 111 specified by the endpoint information and the ECU identifier acquired from the StopSubscribe message is registered in the connection destination list as a server that can participate in the service indicated by the service ID acquired from the StopSubscribe message.

[0228] Also, the processing unit 23 refers to the connection destination list and acquires the unique ID of the in-vehicle ECU 111 specified by the endpoint information and the like acquired from the StopSubscribe message. The processing unit 23 calculates a MAC value based on the StopSubscribe message and the acquired unique ID. Then, the processing unit 23 determines whether the Ethernet frame has been tampered with by comparing the MAC value acquired from the Ethernet frame with the MAC value calculated by itself.

[0229] When the processing unit 23 determines that the in-vehicle ECU 111 specified by the endpoint information and the like acquired from the StopSubscribe message is registered in the connection destination list and the Ethernet frame has not been tampered with, the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is appropriate. On the other hand, when the in-vehicle ECU 111 specified by the endpoint information and the like acquired from the StopSubscribe message is not registered in the connection destination list, or when it is determined that the Ethernet frame has been tampered with, the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate.

[0230] When the processing unit 23 determines that the Ethernet frame is appropriate, it discards the session key K and the key ID corresponding to the service ID included in the StopSubscribe message in the storage unit 25.

[0231] Also, when the processing unit 23 determines that the Ethernet frame is appropriate, it notifies the log generation unit 24 of the reception time te indicated by the timestamp acquired from the Ethernet frame.

[0232] The log generation unit 24 records the reception time by the relay unit 22 of the StopSubscribe message as session information. More specifically, upon receiving the notification of the reception time te from the processing unit 23, the log generation unit 24 writes the notified reception time te as the "end time" of the session log into the session log list R2.

[0233] For example, the relay unit 22 performs relay processing on an Ethernet frame determined by the processing unit 23 to include the StopSubscribe message and determined to be appropriate by the processing unit 23.

[0234] More specifically, when the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is appropriate, it erases the ECU identifier and the endpoint information from the StopSubscribe message included in the Ethernet frame in the storage unit 25. Then, the processing unit 23 outputs a relay instruction indicating that the relay processing of the Ethernet frame should be performed to the relay unit 22.

[0235] When the relay unit 22 receives a relay instruction from the processing unit 23, it acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs relay processing on the Ethernet frame.

[0236] On the other hand, when the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs a discard instruction indicating that the Ethernet frame should be discarded to the relay unit 22.

[0237] When the relay unit 22 receives a discard instruction from the processing unit 23, it discards the Ethernet frame indicated by the discard instruction.

[0238] Also, when the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs a StopSubscribe message and a timestamp to the log generation unit 24.

[0239] Upon receiving the StopSubscribe message and the timestamp, the log generation unit 24 acquires the ECU identifier included in the received StopSubscribe message, and writes the byte sequence of the StopSubscribe message, the acquired ECU identifier, and the reception time as an illegal log to the illegal log list R1 in the storage unit 25.

[0240] (3-3) Reception of StopSubscribe Message by Server Referring to FIG. 5 again, in the server, the processing unit 12 receives an Ethernet frame from the relay device 101 via the communication unit 11, and acquires a StopSubscribe message from the received Ethernet frame. The processing unit 12 decrypts the acquired StopSubscribe message using the session key K in the storage unit 13. The processing unit 12 discards the session key K and the client's endpoint information in the storage unit 13.

[0241] (4) Processing Example 4 in Service Discovery (4-1) Transmission of StopOffer Message by Server In the server, when the processing unit 12 stops providing a service, it generates a StopOffer message including the service ID, ECU identifier, and endpoint information corresponding to the service.

[0242] The processing unit 12 calculates a MAC value based on the generated StopOffer message and the unique ID in the storage unit 13. Further, the processing unit 12 encrypts the StopOffer message using the session key K in the storage unit 13. Then, the processing unit 12 generates an Ethernet frame in which the encrypted StopOffer message and the MAC value are stored in the data field, and the MAC address of the client is stored as the destination MAC address, and transmits the generated Ethernet frame to the relay device 101 via the communication unit 11.

[0243] Also, the processing unit 12 discards the session key K and the client endpoint information in the storage unit 13.

[0244] (4-2) Judgment of the validity of the StopOffer message by the relay device Referring to FIG. 6 again, the relay unit 22 in the relay device 101 receives an Ethernet frame via the corresponding communication port from the server, attaches a timestamp to the received Ethernet frame, and stores the Ethernet frame in the storage unit 25.

[0245] When the Ethernet frame is stored in the storage unit 25 by the relay unit 22, the processing unit 23 confirms that the SOME / IP-SD header is included in the data field of the Ethernet frame, and by referring to the SOME / IP-SD header, determines that the Ethernet frame includes a StopOffer message. Then, the processing unit 23 determines the validity of the Ethernet frame.

[0246] More specifically, the processing unit 23 acquires a StopOffer message, a MAC value, and a timestamp from the Ethernet frame. Further, the processing unit 23 acquires a service ID, endpoint information of the in-vehicle ECU 111, and an ECU identifier from the acquired StopOffer message. Then, the processing unit 23 refers to the connection destination list in the storage unit 25, and checks whether the in-vehicle ECU 111 specified by the endpoint information and the ECU identifier acquired from the StopOffer message is registered in the connection destination list as a client that can participate in the service indicated by the service ID acquired from the StopOffer message.

[0247] Also, the processing unit 23 refers to the connection destination list and acquires the unique ID of the in-vehicle ECU 111 specified by the endpoint information etc. acquired from the StopOffer message. The processing unit 23 calculates a MAC value based on the StopOffer message and the acquired unique ID. Then, the processing unit 23 determines whether the Ethernet frame has been tampered with by comparing the MAC value acquired from the Ethernet frame with the MAC value calculated by itself.

[0248] When the processing unit 23 determines that the in-vehicle ECU 111 specified by the endpoint information etc. acquired from the StopOffer message is registered in the connection destination list and the Ethernet frame has not been tampered with, the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is appropriate. On the other hand, when the processing unit 23 determines that the in-vehicle ECU 111 specified by the endpoint information etc. acquired from the StopOffer message is not registered in the connection destination list, or when it determines that the Ethernet frame has been tampered with, the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate.

[0249] When the processing unit 23 determines that the Ethernet frame is appropriate, it discards the session key K and the key ID corresponding to the service ID included in the StopOffer message in the storage unit 25.

[0250] Further, when the processing unit 23 determines that the Ethernet frame is appropriate, it notifies the log generation unit 24 of the reception time te indicated by the timestamp obtained from the Ethernet frame.

[0251] The log generation unit 24 records, as session information, the reception time by the relay unit 22 of the StopOffer message. More specifically, upon receiving the notification of the reception time te from the processing unit 23, the log generation unit 24 writes the notified reception time te as the "end time" of the session log into the session log list R2.

[0252] For example, the relay unit 22 performs relay processing on an Ethernet frame determined by the processing unit 23 to contain the StopOffer message and determined by the processing unit 23 to be appropriate.

[0253] More specifically, when the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is appropriate, it erases the ECU identifier and endpoint information from the StopOffer message included in the Ethernet frame in the storage unit 25. Then, the processing unit 23 outputs a relay instruction indicating that the relay processing of the Ethernet frame should be performed to the relay unit 22.

[0254] When the relay unit 22 receives a relay instruction from the processing unit 23, it acquires the Ethernet frame indicated by the relay instruction from the storage unit 25 and performs relay processing on the Ethernet frame.

[0255] On the other hand, when the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, it outputs a discard instruction indicating that the Ethernet frame should be discarded to the relay unit 22.

[0256] When the relay unit 22 receives a discard instruction from the processing unit 23, it discards the Ethernet frame indicated by the discard instruction.

[0257] Further, when the processing unit 23 determines that the Ethernet frame received by the relay unit 22 is inappropriate, the processing unit 23 outputs a StopOffer message and a timestamp to the log generation unit 24.

[0258] Upon receiving the StopOffer message and the timestamp, the log generation unit 24 acquires the ECU identifier included in the received StopOffer message, and writes the byte sequence of the StopOffer message, the acquired ECU identifier, and the reception time as an illegal log to the illegal log list R1 in the storage unit 25.

[0259] (4-3) Reception of StopOffer Message by Client Referring to FIG. 5 again, in the client, the processing unit 12 receives an Ethernet frame from the relay device 101 via the communication unit 11, and acquires a StopOffer message from the received Ethernet frame. The processing unit 12 decrypts the acquired StopOffer message using the session key K in the storage unit 13. The processing unit 12 discards the session key K and the server endpoint information in the storage unit 13.

[0260] [Flow of Operations] Each device in the in-vehicle system according to the embodiment of the present disclosure includes a computer including a memory, and an arithmetic processing unit such as a CPU in the computer reads and executes a program including some or all of the steps of the following flowchart and sequence from the memory. The programs of these multiple devices can each be installed from the outside. The programs of these multiple devices are each stored in a recording medium or distributed via a communication line.

[0261] FIG. 11 is a flowchart defining an example of the operation procedure when the relay device according to the first embodiment of the present disclosure distributes a session key.

[0262] Referring to FIG. 11, first, the relay device 101 waits for an Ethernet frame from the in-vehicle ECU 111 (NO in step S102). When an Ethernet frame is received (YES in step S102), the relay device 101 determines whether the received Ethernet frame contains a SOME / IP-SD message. For example, the relay device 101 determines whether the received Ethernet frame contains a SOME / IP-SD message (step S104).

[0263] Next, when the relay device 101 determines that the received Ethernet frame does not contain a SOME / IP-SD message (NO in step S106), the relay device 101 performs relay processing on the Ethernet frame (step S108).

[0264] Next, the relay device 101 waits for a new Ethernet frame from the in-vehicle ECU 111 (NO in step S102).

[0265] On the other hand, when the relay device 101 determines that the received Ethernet frame contains a SOME / IP-SD message (YES in step S106), the relay device 101 determines the suitability of the Ethernet frame (step S110).

[0266] Next, when the relay device 101 determines that the received Ethernet frame is appropriate (YES in step S112), the relay device 101 performs relay processing and the like on the Ethernet frame (step S114). Details of step S114 will be described later.

[0267] Next, the relay device 101 waits for a new Ethernet frame from the in-vehicle ECU 111 (NO in step S102).

[0268] On the other hand, when the relay device 101 determines that the received Ethernet frame is inappropriate (NO in step S112), it writes the byte sequence of the message included in the Ethernet frame, the ECU identifier included in the message, and the reception time of the Ethernet frame into the illegal log list R1 as an illegal log (step S116).

[0269] Next, the relay device 101 discards the received Ethernet frame (step S118) and waits for a new Ethernet frame from the in-vehicle ECU 111 (NO in step S102).

[0270] FIG. 12 is a flowchart defining an example of the operation procedure when the relay device according to the first embodiment of the present disclosure distributes a session key. FIG. 12 shows the details of step S114 in FIG. 11.

[0271] Referring to FIG. 12, first, when the relay device 101 determines that the received Ethernet frame includes an Offer message or a Find message (YES in step S202), it stores the server information or the client information in the storage unit 25. More specifically, when the relay device 101 determines that the received Ethernet frame includes an Offer message, it stores the ECU identifier and the endpoint information obtained from the Offer message in the storage unit 25 as server information. On the other hand, when the relay device 101 determines that the received Ethernet frame includes a Find message, it stores the ECU identifier and the endpoint information obtained from the Find message in the storage unit 25 as client information (step S204).

[0272] Next, the relay device 101 performs the relay process of the received Ethernet frame (step S206).

[0273] On the other hand, when the relay device 101 determines that the received Ethernet frame contains a Subscribe message (NO in step S202 and YES in step S208), it stores the ECU identifier and endpoint information obtained from the Subscribe message as client information in the storage unit 25 (step S210).

[0274] Next, the relay device 101 decides to establish a session between the server and the client, and generates a session key K to be used for the session (step S212).

[0275] Next, the relay device 101 transmits the generated session key K to the clients participating in the session. More specifically, the relay device 101 generates a start message MC including an encryption key KC, and transmits an Ethernet frame including the generated start message MC to the clients (step S214).

[0276] Next, the relay device 101 performs relay processing on the received Ethernet frame. More specifically, the relay device 101 includes an encryption key KS in the Subscribe message included in the received Ethernet frame, and transmits the Ethernet frame to the server (step S216).

[0277] Next, the relay device 101 writes the service ID of the service provided in the session to be established, the ECU identifiers of the server and the clients which are the destinations of the session key K, and the start time of the session, respectively, as "Service ID", "ECU Identifier" and "Start Time" of the session log in the session log list R2 (step S218).

[0278] On the one hand, when the relay device 101 determines that the received Ethernet frame contains a StopSubscribe message or a StopOffer message (NO in step S202 and NO in step S208), it writes the reception time te of the Ethernet frame as the "end time" of the session log to the session log list R2 (step S220).

[0279] Next, the relay device 101 performs relay processing on the received Ethernet frame (step S222).

[0280] FIG. 13 is a diagram showing an example of a communication sequence in an in-vehicle system according to the first embodiment of the present disclosure. FIG. 13 shows a communication sequence in an in-vehicle system 301 including a server S1 and clients C1, C2.

[0281] Referring to FIG. 13, first, the server S1 transmits an Ethernet frame in which an Offer message is stored in the data field and a multicast address is stored as the destination MAC address to the relay device 101 (step S302).

[0282] Next, the relay device 101 determines that the Ethernet frame received from the server S1 contains an Offer message, and determines the suitability of the Ethernet frame. Then, the relay device 101 determines that the Ethernet frame is appropriate and performs relay processing on the Ethernet frame (step S304).

[0283] Next, for example, the client C1 obtains an Offer message from the Ethernet frame received from the server S1 via the relay device 101 and determines that the service provided by the server S1 is required. Then, the client C1 transmits an Ethernet frame in which a Subscribe message is stored in the data field and the MAC address of the server S1 is stored as the destination MAC address to the relay device 101 (step S306).

[0284] Next, the relay device 101 determines that the Ethernet frame received from the client C1 includes a Subscribe message, and determines the suitability of the Ethernet frame. Then, the relay device 101 determines that the Ethernet frame is appropriate, decides to establish a session between the server S1 and the client C1, and generates a session key K1 to be used for the session. At this time, the relay device 101 writes the service ID of the service provided in the established session, the ECU identifiers of the server S1 and the client C1, and the start time of the session into the session log list R2 as the "service ID", "ECU identifier", and "start time" of the session log, respectively (step S308).

[0285] Next, the relay device 101 includes the session key K1 in the Subscribe message included in the Ethernet frame received from the client C1, and transmits the Ethernet frame to the server S1 (step S310).

[0286] In addition, the relay device 101 generates a start message MC including the session key K1, and transmits an Ethernet frame including the generated start message MC to the client C1 (step S312).

[0287] Next, for example, the server S1 periodically generates an Ethernet frame storing a session message encrypted using the session key K1, and transmits the generated Ethernet frame to the client C1 via the relay device 101 (step S314).

[0288] Next, for example, the client C2 obtains an Offer message from the Ethernet frame received from the server S1 via the relay device 101, and determines that the service provided by the server S1 is required. Then, the client C2 transmits an Ethernet frame in which a Subscribe message is stored in the data field and the MAC address of the server S1 is stored as the destination MAC address to the relay device 101 (step S316).

[0289] Next, the relay device 101 determines that the Ethernet frame received from the client C2 contains a Subscribe message, and determines the suitability of the Ethernet frame. Then, the relay device 101 determines that the Ethernet frame is appropriate, decides to establish a session between the server S1 and the client C2, and generates a session key K2 to be used for the session. Also, at this time, the relay device 101 writes the service ID of the service provided in the session to be established, the ECU identifiers of the server S1 and the client C2, and the start time of the session, as the "service ID", "ECU identifier", and "start time" of the session log, respectively, in the session log list R2 (step S318).

[0290] Next, the relay device 101 includes the session key K2 in the Subscribe message included in the Ethernet frame received from the client C2, and transmits the Ethernet frame to the server S1 (step S320).

[0291] Also, the relay device 101 generates a start message MC including the session key K2, and transmits an Ethernet frame including the generated start message MC to the client C2 (step S322).

[0292] Next, the server S1 generates, for example, periodically, an Ethernet frame storing a session message encrypted using the session key K1, and transmits the generated Ethernet frame to the client C1 via the relay device 101 (step S324).

[0293] Also, the server S1 generates, for example, periodically, an Ethernet frame storing a session message encrypted using the session key K2, and transmits the generated Ethernet frame to the client C2 via the relay device 101 (step S326).

[0294] Next, for example, client C1 transmits an Ethernet frame in which a StopSubscribe message is stored in the data field and the MAC address of server S1 is stored as the destination MAC address to relay device 101 (step S328).

[0295] Next, relay device 101 determines that the Ethernet frame received from client C1 contains a StopSubscribe message, and determines the suitability of the Ethernet frame. Then, relay device 101 determines that the Ethernet frame is appropriate, and performs relay processing on the Ethernet frame. Also, at this time, relay device 101 writes the reception time te of the Ethernet frame as the "end time" of the session log to session log list R2 (step S330).

[0296] Next, client C1 discards the session key K1 and the endpoint information of server S1 in storage unit 13 (step S332).

[0297] Also, server S1 discards the session key K1 and the endpoint information of client C1 in storage unit 13 (step S334).

[0298] Next, server S1 continues to transmit the Ethernet frame in which the session message is stored to client C2 (step S336).

[0299] FIG. 14 is a diagram showing another example of a communication sequence in an in-vehicle system according to the first embodiment of the present disclosure. FIG. 14 shows a communication sequence in in-vehicle system 301 including servers S2 and S3 and client C1.

[0300] Referring to FIG. 14, first, client C1 transmits an Ethernet frame in which a Find message is stored in the data field and a multicast address is stored as the destination MAC address to relay device 101 (step S402).

[0301] Next, the relay device 101 determines that the Ethernet frame received from the client C1 contains a Find message, and determines the suitability of the Ethernet frame. Then, the relay device 101 determines that the Ethernet frame is appropriate and performs relay processing on the Ethernet frame (step S404).

[0302] Next, for example, the server S2 transmits an Ethernet frame in which an Offer message is stored in the data field and the MAC address of the client C1 is stored as the destination MAC address to the relay device 101 (step S406).

[0303] Next, the relay device 101 determines that the Ethernet frame received from the server S2 contains an Offer message, and determines the suitability of the Ethernet frame. Then, the relay device 101 determines that the Ethernet frame is appropriate and performs relay processing on the Ethernet frame (step S408).

[0304] Next, the client C1 transmits an Ethernet frame in which a Subscribe message is stored in the data field and the MAC address of the server S2 is stored as the destination MAC address to the relay device 101 (step S410).

[0305] Next, the relay device 101 determines that the Ethernet frame received from the client C1 contains a Subscribe message, and determines the suitability of the Ethernet frame. Then, the relay device 101 determines that the Ethernet frame is appropriate, decides to establish a session between the server S2 and the client C1, and generates a session key K3 to be used for the session. Also, at this time, the relay device 101 writes the service ID of the service provided in the established session, the ECU identifiers of the server S3 and the client C1, and the start time of the session, as "Service ID", "ECU Identifier", and "Start Time" of the session log, respectively, into the session log list R2 (step S412).

[0306] Next, the relay device 101 includes the session key K3 in the Subscribe message included in the Ethernet frame received from the client C1, and transmits the Ethernet frame to the server S2 (step S414).

[0307] Also, the relay device 101 generates a start message MC including the session key K3, and transmits an Ethernet frame including the generated start message MC to the client C1 (step S416).

[0308] Next, the server S2 generates, for example, periodically, an Ethernet frame storing a session message encrypted using the session key K3, and transmits the generated Ethernet frame to the client C1 via the relay device 101 (step S418).

[0309] Next, for example, the server S2 transmits an Ethernet frame in which a StopOffer message is stored in the data field and the MAC address of the client C1 is stored as the destination MAC address to the relay device 101 (step S420).

[0310] Next, the relay device 101 determines that the Ethernet frame received from the server S2 contains a StopOffer message, and determines the suitability of the Ethernet frame. Then, the relay device 101 determines that the Ethernet frame is appropriate and performs relay processing on the Ethernet frame. Also, at this time, the relay device 101 writes the reception time te of the Ethernet frame as the "end time" of the session log to the session log list R2 (step S422).

[0311] Next, the server S2 discards the session key K3 and the endpoint information of the client C1 in the storage unit 13 (step S424).

[0312] Also, the client C1 discards the session key K3 and the endpoint information of the server S1 in the storage unit 13 (step S426).

[0313] Note that in the in-vehicle system 301 according to the first embodiment of the present disclosure, when an abnormality in the in-vehicle system 301 is detected while the server is transmitting information to a plurality of clients by multicast, it is configured to switch to a state of transmitting information to the plurality of clients by unicast. However, the present disclosure is not limited to this. The server may be configured not to switch to a state of transmitting information to a plurality of clients by unicast. Also, the server may be configured to be able to transmit information by multicast while transmitting information to a plurality of clients by unicast.

[0314] Also, in the in-vehicle system 301 according to the first embodiment of the present disclosure, it is assumed that the relay device 101 and the in-vehicle ECU 111 are connected without passing through another relay device. However, the present disclosure is not limited to this. The relay device 101 and the in-vehicle ECU 111 may be configured to be connected via another relay device. In this case, for example, the other relay device relays all Ethernet frames received from the in-vehicle ECU 111 connected to the other relay device to the relay device 101.

[0315] Also, in the relay device 101 according to the first embodiment of the present disclosure, although the processing unit 23 is configured to transmit the session key K encrypted using the unique ID as an encryption key to the in-vehicle ECU 111 having the unique ID via the relay unit 22, the present disclosure is not limited thereto. The processing unit 23 may be configured to transmit the unencrypted session key K to the in-vehicle ECU 111 via the relay unit 22.

[0316] Also, in the relay device 101 according to the first embodiment of the present disclosure, although the processing unit 23 is configured to transmit the hash value HV calculated using the unique ID and the session key K to the in-vehicle ECU 111 having the unique ID via the relay unit 22, the present disclosure is not limited thereto. The processing unit 23 may be configured not to transmit the hash value HV to the in-vehicle ECU 111.

[0317] Also, the relay device 101 according to the first embodiment of the present disclosure is configured to include the log generation unit 24, but the present disclosure is not limited thereto. The relay device 101 may be configured not to include the log generation unit 24.

[0318] Also, in the relay device 101 according to the first embodiment of the present disclosure, although the log generation unit 24 is configured to write the start time and end time of the session to the session log list R2, the present disclosure is not limited thereto. The log generation unit 24 may be configured to write the service ID of the service provided in the session, the ECU identifier of the server participating in the session, and the ECU identifier of the client participating in the session to the session log list R2, while not writing at least one of the start time and end time of the session to the session log list R2.

[0319] Further, in the relay device 101 according to the first embodiment of the present disclosure, although the processing unit 23 is configured to determine the suitability of the Ethernet frame received by the relay unit 22 when it determines that the Ethernet frame includes a SOME / IP-SD message, the present disclosure is not limited thereto. The processing unit 23 may be configured not to determine the suitability of the Ethernet frame including the SOME / IP-SD message.

[0320] Further, in the relay device 101 according to the first embodiment of the present disclosure, although the processing unit 23 is configured to generate a session key K with random content for each session, the present disclosure is not limited thereto. The processing unit 23 may be configured to generate a session key K with regular content for each session.

[0321] By the way, a technology capable of further improving the security in the in-vehicle network is desired. More specifically, for example, in an in-vehicle system that performs service-oriented communication, a technology capable of further improving the security in the in-vehicle network is desired.

[0322] On the other hand, in the relay device 101 according to the first embodiment of the present disclosure, the relay unit 22 performs a relay process of transmitting a plurality of Ethernet frames respectively received from a plurality of in-vehicle ECUs 111 to the destination in-vehicle ECU 111. The processing unit 23 determines that the plurality of Ethernet frames received by the relay unit 22 include a start request and a start response. The processing unit 23 generates a session key K for each session to be used in a session in which the in-vehicle ECU 111 that is the transmission source of the Ethernet frame determined to include the start request and one or a plurality of in-vehicle ECUs 111 that are the transmission sources of the Ethernet frames determined to include the start response participate. The processing unit 23 transmits the generated session key K to each in-vehicle ECU 111 participating in the session via the relay unit 22.

[0323] In this way, in the relay device 101, it is determined whether the received frame includes a start request and whether the received frame includes a start response, and a session key K used for a session in which the in-vehicle ECU 111 that is the transmission source of the frame including the start request and one or a plurality of in-vehicle ECUs 111 that are the transmission sources of the frames including the start response participate is generated for each session and transmitted to each in-vehicle ECU 111. Thus, communication using individual session keys K for each session can be performed between the in-vehicle ECUs 111, so that the security of communication between the in-vehicle ECUs 111 can be improved. Also, for example, by performing authentication of the in-vehicle ECU 111 that is the transmission source of the start request and the in-vehicle ECU 111 that is the transmission source of the start response and then generating and transmitting a common key, participation in the session by unauthorized devices can be prevented. Therefore, the security in the in-vehicle network can be further improved.

[0324] Also, in the relay device 101, when the number of clients communicating with one server in a session reaches a predetermined number, the processing unit 23 generates a session key KM used for the session between the server and the plurality of clients, and distributes the generated session key KM to the server and the plurality of clients. Thus, multicast communication using the session key KM can be performed between the server and the plurality of clients. Therefore, the security in the in-vehicle network where messages conforming to SOME / IP are transmitted and received can be improved.

[0325] In addition, in the configuration where the relay device 101 generates the session key K, compared with the configuration where a management device other than the relay device 101 receives the start request and the start response and generates the session key K, while the in-vehicle ECUs 111 exchange the start request and the start response according to the existing specifications, the relay device 101 can generate the session key K. Also, compared with the configuration where a management device other than the relay device 101 receives the start request and the start response and generates the session key K, the hardware configuration can be simplified, and since there is no need to transfer the frame including the start request and the frame including the start response from the relay device to the management device, the communication traffic in the in-vehicle network can be reduced.

[0326] Next, another embodiment of the present disclosure will be described with reference to the drawings. In the drawings, the same or corresponding parts are denoted by the same reference numerals and their description will not be repeated.

[0327] 〔Second Embodiment〕 This embodiment relates to an in-vehicle system 302 in which a management device 201, which is a device different from the relay device 101, generates the session key K, compared with the in-vehicle system 301 according to the first embodiment. It is the same as the in-vehicle system 301 according to the first embodiment except for the content described below.

[0328] <In-vehicle system> FIG. 15 is a diagram showing the configuration of an in-vehicle system according to the second embodiment of the present disclosure. Referring to FIG. 15, the in-vehicle system 302 includes a relay device 102 instead of the relay device 101 and further includes a management device 201, compared with the in-vehicle system 301. The in-vehicle ECU 111 and the relay device 102 are examples of in-vehicle devices. The in-vehicle system 302 is mounted on the vehicle 1. The management device 201 is used for the in-vehicle system 302.

[0329] The relay device 102 is connected to the management device 201 and each in-vehicle ECU 111 via the cable 14. The management device 201, the in-vehicle ECU 111, and the relay device 102 constitute an in-vehicle network.

[0330] The relay device 102 is, for example, a Central Gateway (CGW) and can communicate with the management device 201 and the in-vehicle ECU 111. The relay device 102 performs relay processing for relaying information exchanged between a plurality of in-vehicle ECUs 111 connected to different cables 14 and information exchanged between the in-vehicle ECU 111 and the management device 201. Hereinafter, communication between in-vehicle ECUs 111 and communication between the management device 201 and the in-vehicle ECU 111 are assumed to be performed via the relay device 102 unless otherwise specified.

[0331] (Offer message) For example, a certain in-vehicle ECU 111, as a server, periodically or irregularly transmits an Offer message including a service ID corresponding to a service that the ECU itself can provide, to the management device 201. The Offer message is an example of a session start request.

[0332] The management device 201 receives the Offer message from the server and determines the suitability of the received Offer message. If the management device 201 determines that the received Offer message is inappropriate, it discards the Offer message. On the other hand, if the management device 201 determines that the received Offer message is appropriate, it multicasts the Offer message to a plurality of in-vehicle ECUs 111.

[0333] Among the plurality of in-vehicle ECUs 111 that have received the Offer message from the management device 201, the in-vehicle ECU 111 that requires the service corresponding to the service ID included in the Offer message, as a client, transmits a Subscribe message indicating a request for the service, to the management device 201. The Subscribe message is an example of a start response to a session start request.

[0334] When the management device 201 receives a Subscribe message from a client, it decides to establish a session between the server and the client. Then, the management device 201 generates a session key K unique to the session for use in the session. That is, the management device 201 generates a session key K for each session for use in the session. The session key K is an example of a common key and is, for example, a random number with a key length according to the encryption method used. For example, the management device 201 generates a session key K with random content for each session. The management device 201 transmits the generated session key K to the server and the client participating in the session.

[0335] (Find message) For example, a certain in-vehicle ECU 111, as a client, periodically or irregularly transmits a Find message including a service ID corresponding to the service to be received to the management device 201. The Find message is an example of a session search request.

[0336] The management device 201 receives a Find message from the client and determines the suitability of the received Find message. If the management device 201 determines that the received Find message is inappropriate, it discards the Find message. On the other hand, if the management device 201 determines that the received Find message is appropriate, it multicasts the Find message to a plurality of in-vehicle ECUs 111.

[0337] Among the plurality of in-vehicle ECUs 111 that have received the Find message from the management device 201, the in-vehicle ECU 111 that can provide the service corresponding to the service ID included in the Find message, as a server, transmits an Offer message indicating that the service can be provided to the management device 201. The Offer message is an example of a start request for a session search request.

[0338] The management device 201 receives an Offer message from the server and determines the suitability of the received Offer message. When the management device 201 determines that the received Offer message is inappropriate, it discards the Offer message. On the other hand, when the management device 201 determines that the received Offer message is appropriate, it sends the Offer message to the client.

[0339] The client that has received the Offer message from the management device 201 sends a Subscribe message to the management device 201. The Subscribe message is an example of a start response to a start request for a session.

[0340] When the management device 201 receives the Subscribe message from the client, it decides to establish a session between the server and the client. Then, the management device 201 generates a session key K unique to the session for use in the session. The management device 201 sends the generated session key K to the server and the client participating in the session.

[0341] <Processing in the in-vehicle ECU and the management device> FIG. 16 is a diagram showing the configuration of the management device according to the second embodiment of the present disclosure. Referring to FIG. 16, the management device 201 includes a receiving unit 31, a transmitting unit 32, a processing unit 33, a log generation unit 34, and a storage unit 35. The processing unit 33 is an example of a generation unit. The log generation unit 34 is an example of a recording unit. The receiving unit 31, the transmitting unit 32, the processing unit 33, and the log generation unit 34 are realized by a processor such as a CPU and a DSP, for example. The storage unit 35 is a non-volatile memory, for example.

[0342] The receiving unit 31 receives a session start request and a start response to the start request from each of the plurality of in-vehicle ECUs 111. The processing unit 33 generates a session key K unique to the session to be used for the session associated with the start request and the start response received by the receiving unit 31. That is, the processing unit 33 generates a session key K to be used for the session in which the in-vehicle ECU 111 that is the source of the start request received by the receiving unit 31 and the in-vehicle ECU 111 that is the source of the start response received by the receiving unit 31 participate. For example, the processing unit 33 generates a session key K with random content for each session. The transmitting unit 32 transmits the session key K generated by the processing unit 33 to each in-vehicle ECU 111 participating in the session. The log generation unit 34 records session information regarding the session in which the session key K generated by the processing unit 33 is used.

[0343] The storage unit 35 stores the unique IDs of the respective in-vehicle ECUs 111 in the in-vehicle system 302. For example, the storage unit 35 stores the connection destination list shown in FIG. 7.

[0344] (1) Processing Example 1 in Service Discovery (1-1) Transmission of Offer Message by Server Referring to FIG. 5 again, in the in-vehicle ECU 111 which is a server, the processing unit 12 refers to the service list in the storage unit 13 and acquires a service ID corresponding to the service that the ECU itself can provide. Further, the processing unit 12 acquires the ECU identifier and the endpoint information of its own in-vehicle ECU 111 from the storage unit 13. The processing unit 12 generates an Offer message including the acquired service ID, ECU identifier, and endpoint information.

[0345] The processing unit 12 calculates a MAC value based on the generated Offer message and the unique ID in the storage unit 13. The processing unit 12 outputs the generated Offer message and the calculated MAC value to the communication unit 11.

[0346] The communication unit 11 receives the Offer message and the MAC value from the processing unit 12, and transmits the received Offer message and MAC value to the management device 201.

[0347] (1-2) Judgment on the suitability of the Offer message by the management device Referring to FIG. 16 again, the receiving unit 31 in the management device 201 receives the Offer message and the MAC value from the server. The receiving unit 31 attaches a timestamp to the received Offer message, and outputs the Offer message and the MAC value to the processing unit 33.

[0348] The processing unit 33 receives the Offer message and the MAC value from the receiving unit 31, and judges the suitability of the received Offer message.

[0349] More specifically, the processing unit 33 acquires the service ID, the endpoint information of the in-vehicle ECU 111, and the ECU identifier from the Offer message. Then, the processing unit 33 refers to the connection destination list in the storage unit 35, and checks whether the in-vehicle ECU 111 specified by the endpoint information and the ECU identifier acquired from the Offer message is registered in the connection destination list as a server that can participate in the service indicated by the service ID acquired from the Offer message.

[0350] As an example, when the service ID, the endpoint information, and the ECU identifier acquired from the Offer message are "0x0001", "BBB", and "ECU_2", respectively, the processing unit 33 determines that the in-vehicle ECU 111 specified by the ECU identifier and the endpoint information is registered in the connection destination list as a server that can participate in the service indicated by the service ID.

[0351] Further, the processing unit 33 refers to the connection destination list and acquires the unique ID of the in-vehicle ECU 111 specified by the endpoint information and the like acquired from the Offer message. The processing unit 33 calculates a MAC value based on the Offer message and the acquired unique ID. Then, the processing unit 33 determines whether the Offer message has been tampered with by comparing the MAC value received from the receiving unit 31 with the MAC value calculated by itself.

[0352] When the processing unit 33 determines that the in-vehicle ECU 111 specified by the endpoint information and the like acquired from the Offer message is registered in the connection destination list and the Offer message has not been tampered with, the processing unit 33 determines that the Offer message received by the receiving unit 31 is appropriate. On the other hand, when the in-vehicle ECU 111 specified by the endpoint information and the like acquired from the Offer message is not registered in the connection destination list, or when the processing unit 33 determines that the Offer message has been tampered with, the processing unit 33 determines that the Offer message received by the receiving unit 31 is inappropriate.

[0353] When the processing unit 33 determines that the Offer message received by the receiving unit 31 is appropriate, the processing unit 33 stores the ECU identifier and endpoint information acquired from the Offer message in the storage unit 35 as server information. Further, the processing unit 33 outputs the Offer message to the transmission unit 32.

[0354] The transmission unit 32 multicasts the Offer message received from the processing unit 33 to a plurality of clients. For example, the transmission unit 32 refers to the connection destination list in the storage unit 35 and multicasts to a plurality of clients that may require a service with a service ID of "0x0001".

[0355] On the other hand, when the processing unit 33 determines that the Offer message received by the receiving unit 31 is inappropriate, the processing unit 33 outputs the Offer message to the log generation unit 34. The log generation unit 34 records information regarding the message determined to be inappropriate by the processing unit 33.

[0356] The storage unit 35 stores an illegal log list R11 which is a list of illegal logs indicating the byte sequence of the message determined to be inappropriate by the processing unit 33, the ECU identifier of the in-vehicle ECU 111 which is the transmission source of the message, and the reception time of the message. The illegal log list R11 is a list with the same content as the illegal log list R1 shown in FIG. 8.

[0357] Upon receiving an Offer message from the processing unit 33, the log generation unit 34 acquires the ECU identifier included in the received Offer message and a timestamp indicating the reception time, and writes the byte sequence of the Offer message, the acquired ECU identifier, and the reception time into the illegal log list R11 in the storage unit 35 as an illegal log. Thereafter, the log generation unit 34 discards the Offer message.

[0358] (1-3) Transmission of Subscribe message by client Referring to FIG. 5 again, in the in-vehicle ECU 111 which is a client, the communication unit 11 receives an Offer message from the management device 201 and outputs the received Offer message to the processing unit 12.

[0359] Upon receiving an Offer message from the communication unit 11, the processing unit 12 acquires a service ID from the received Offer message. The processing unit 12 refers to the service list in the storage unit 13 and determines the necessity of the service indicated by the acquired service ID. When the processing unit 12 determines that the service is necessary, it outputs a reply instruction to the communication unit 11. On the other hand, when the processing unit 12 determines that the service is unnecessary, it does not output a reply instruction.

[0360] Upon receiving a reply instruction from the processing unit 12, the communication unit 11 acquires an ECU identifier and the endpoint information of its own in-vehicle ECU 111 from the storage unit 13. Then, the communication unit 11 generates a Subscribe message including the ECU identifier and the endpoint information, and transmits the generated Subscribe message to the management device 201.

[0361] (1-4) Determination of Session Establishment by the Management Device Referring again to FIG. 16, the receiving unit 31 in the management device 201 receives a Subscribe message from the client and outputs the received Subscribe message to the processing unit 33.

[0362] Upon receiving the Subscribe message from the receiving unit 31, the processing unit 33 acquires the ECU identifier and endpoint information from the received Subscribe message. The processing unit 33 stores the acquired ECU identifier and endpoint information in the storage unit 35 as client information.

[0363] The processing unit 33 determines to establish a session between the server and the client indicated by the server information and the client information stored in the storage unit 35, respectively. When the processing unit 33 determines to establish a session, it generates a session key K and distributes it to the server and the client.

[0364] For example, if the processing unit 33 does not receive a Subscribe message from the client via the receiving unit 31 within a predetermined time after transmitting an Offer message to the client via the transmitting unit 32, the processing unit 33 transmits a message indicating that there is no client requiring the service to the server via the transmitting unit 32.

[0365] (1-5) Distribution of Session Key by the Management Device The processing unit 33 generates a session key K to be used for the session determined to be established and a key ID that is the ID of the session key K, and distributes the generated session key K and key ID to the server and the client participating in the session.

[0366] For example, the processing unit 33 encrypts the session key K using the unique ID as the encryption key. Also, for example, the processing unit 33 calculates a hash value HV calculated using the unique ID and the session key K.

[0367] More specifically, the processing unit 33 refers to the connection destination list in the storage unit 35, obtains the unique ID of the server indicated by the server information, and encrypts the session key K using the obtained unique ID as an encryption key, thereby generating an encryption key KS which is the encrypted session key K for the server. Then, the processing unit 33 includes the encryption key KS and the corresponding key ID in the Subscribe message received from the client, and calculates a hash value HVS by applying the Subscribe message and the obtained unique ID to a predetermined hash function. Note that the processing unit 33 may further include in the Subscribe message information indicating that there is a client that requires a service.

[0368] In addition, the processing unit 33 refers to the connection destination list in the storage unit 35, obtains the unique ID of the client indicated by the client information, and encrypts the session key K using the obtained unique ID as an encryption key, thereby generating an encryption key KC which is the encrypted session key K for the client. Then, the processing unit 33 generates a start message MC including the endpoint information of the server, the encryption key KC, and the corresponding key ID, and calculates a hash value HVC by applying the generated start message MC and the obtained unique ID to a predetermined hash function. Note that the processing unit 33 may include in the start message MC information indicating that there is a server capable of providing a service.

[0369] The processing unit 33 outputs the generated start message MC and Subscribe message, as well as the calculated hash values HVS and HVC, to the transmission unit 32.

[0370] The transmission unit 32 transmits the Subscribe message received from the processing unit 33 to the server having the unique ID used for encryption of the encryption key KS. In addition, the transmission unit 32 transmits the start message MC to the client having the unique ID used for encryption of the encryption key KC. Further, the transmission unit 32 transmits the hash value HVS to the server and the hash value HVC to the client.

[0371] The processing unit 33 outputs session information indicating the service ID of the service provided in the established session, the ECU identifier of the server that is the destination of the Subscribe message, the ECU identifier of the client that is the destination of the start message MC, and the output time ts of the Subscribe message and the start message MC to the log generation unit 34. The output time ts indicates the transmission time by the transmission unit 32 of the session key K.

[0372] The log generation unit 34 records the session information regarding the session in which the session key K generated by the processing unit 33 is used.

[0373] The storage unit 35 stores a session log list R12 that is a list of session logs indicating the service ID of the service provided in the established session, the ECU identifiers of the server and the client that are the distribution destinations of the session key K, the start time of the session, and the end time of the session. The session log list R12 is a list with the same content as the session log list R12 shown in FIG. 9.

[0374] The log generation unit 34 receives the session information from the processing unit 33 and writes the service ID, ECU identifier, and output time ts included in the received session information to the session log list R12 as the "service ID", "ECU identifier", and "start time" of the session log, respectively.

[0375] Referring to FIG. 5 again, in the server, the communication unit 11 receives the Subscribe message and the hash value HVS from the management device 201 and outputs them to the processing unit 12. The processing unit 12 collates the hash value calculated using the session key K from the management device 201 received by the communication unit 11 and its own unique ID with the hash value HVS from the management device 201 received by the communication unit 11.

[0376] More specifically, the processing unit 12 receives the Subscribe message and the hash value HVS from the communication unit 11, obtains the unique ID from the storage unit 13, and calculates a hash value by applying the received Subscribe message and the obtained unique ID to a predetermined hash function. The processing unit 12 determines whether the Subscribe message has been tampered with by comparing the hash value HVS with the hash value calculated by itself.

[0377] If the processing unit 12 determines that the Subscribe message has been tampered with, it discards the Subscribe message. On the other hand, if the processing unit 12 determines that the Subscribe message has not been tampered with, it obtains the client's endpoint information, the encryption key KS, and the key ID from the Subscribe message. Then, the processing unit 12 obtains the session key K by decrypting the encryption key KS using the unique ID.

[0378] If the key ID of the session key K obtained in the past is stored in the storage unit 13, the processing unit 12 compares the key ID in the storage unit 13 with the newly obtained key ID. When the processing unit 12 confirms that the key ID in the storage unit 13 is different from the newly obtained key ID, it stores the newly obtained client's endpoint information, session key K, and key ID in the storage unit 13.

[0379] On the other hand, if the key ID in the storage unit 13 matches the newly obtained key ID, the processing unit 12 transmits a message requesting retransmission of the session key K to the management device 201 via the communication unit 11. When the management device 201 receives the message, it generates a new session key K and transmits it to the server and the client. As a result, when the same session key K used in a past session is distributed to the server and the client, the management device 201 can be prompted to regenerate the session key K, so that it is possible to avoid a decrease in security caused by the same session key K being used in different sessions.

[0380] Also, in the client, the communication unit 11 receives the start message MC and the hash value HVC from the management device 201 and outputs them to the processing unit 12. The processing unit 12 collates the hash value calculated using the session key K from the management device 201 received by the communication unit 11 and its own unique ID with the hash value HVC received from the management device 201 by the communication unit 11.

[0381] More specifically, the processing unit 12 receives the start message MC and the hash value HVC from the communication unit 11, acquires the unique ID from the storage unit 13, and calculates the hash value by giving the received start message MC and the acquired unique ID to a predetermined hash function. The processing unit 12 determines whether the start message MC has been tampered with by collating the hash value HVC with the hash value calculated by itself.

[0382] If the processing unit 12 determines that the start message MC has been tampered with, it discards the start message MC. On the other hand, if the processing unit 12 determines that the start message MC has not been tampered with, it acquires the server endpoint information, the encryption key KC, and the key ID from the start message MC. Then, the processing unit 12 acquires the session key K by decrypting the encryption key KC using the unique ID.

[0383] If the key ID of the session key K acquired in the past is stored in the storage unit 13, the processing unit 12 compares the key ID in the storage unit 13 with the newly acquired key ID. When the processing unit 12 confirms that the key ID in the storage unit 13 is different from the newly acquired key ID, it stores the newly acquired server endpoint information, session key K, and key ID in the storage unit 13.

[0384] On the other hand, when the key ID in the storage unit 13 matches the newly acquired key ID, the processing unit 12 transmits, via the communication unit 11, a message requesting retransmission of the session key K to the management device 201. When receiving the message, the management device 201 generates a new session key K and transmits it to the server and the client.

[0385] Here, since the number of different session keys K that can be generated by the management device 201 is finite, the management device 201 may distribute the same session key K as a certain session key K after a sufficient time has passed after the distribution of a certain session key K. Therefore, the processing unit 12 in the server and the client deletes the key ID from the storage unit 13 after a sufficient time has elapsed since the key ID was stored in the storage unit 13.

[0386] (2) Example of processing in Service Discovery 2 (2-1) Transmission of Find message by client Referring to FIG. 5 again, in the in-vehicle ECU 111 which is a client, the processing unit 12 refers to the service list in the storage unit 13 and acquires the service ID corresponding to the service that the client intends to receive. Further, the processing unit 12 acquires the ECU identifier and the endpoint information of its own in-vehicle ECU 111 from the storage unit 13. The processing unit 12 generates a Find message including the acquired service ID, ECU identifier, and endpoint information.

[0387] The processing unit 12 calculates a MAC value based on the generated Find message and the unique ID in the storage unit 13. The processing unit 12 outputs the generated Find message and the calculated MAC value to the communication unit 11.

[0388] The communication unit 11 receives the Find message and the MAC value from the processing unit 12, and transmits the received Find message and MAC value to the management device 201.

[0389] (2-2) Determination of suitability of Find message by management device Referring again to FIG. 16, the receiving unit 31 in the management device 201 receives a Find message and a MAC value from the client. The receiving unit 31 attaches a timestamp to the received Find message and outputs the Find message and the MAC value to the processing unit 33.

[0390] Upon receiving the Find message and the MAC value from the receiving unit 31, the processing unit 33 determines the propriety of the received Find message.

[0391] More specifically, the processing unit 33 acquires the service ID, the endpoint information of the in-vehicle ECU 111, and the ECU identifier from the Find message. Then, the processing unit 33 refers to the connection destination list in the storage unit 35 and checks whether the in-vehicle ECU 111 specified by the endpoint information and the ECU identifier acquired from the Find message is registered in the connection destination list as a client that can participate in the service indicated by the service ID acquired from the Find message.

[0392] As an example, when the service ID, the endpoint information, and the ECU identifier acquired from the Find message are "0x0001", "CCC", and "ECU_3", respectively, the processing unit 33 determines that the in-vehicle ECU 111 specified by the ECU identifier and the endpoint information is registered in the connection destination list as a client that can participate in the service indicated by the service ID.

[0393] Also, the processing unit 33 refers to the connection destination list and acquires the unique ID of the in-vehicle ECU 111 specified by the endpoint information and the like acquired from the Find message. The processing unit 33 calculates a MAC value based on the Find message and the acquired unique ID. Then, the processing unit 33 determines whether the Find message has been tampered with by comparing the MAC value received from the receiving unit 31 with the MAC value calculated by itself.

[0394] When the in-vehicle ECU 111 identified by the endpoint information etc. obtained from the Find message is registered in the connection destination list and the processing unit 33 determines that the Find message has not been tampered with, the processing unit 33 determines that the Find message received by the receiving unit 31 is appropriate. On the other hand, when the in-vehicle ECU 111 identified by the endpoint information etc. obtained from the Find message is not registered in the connection destination list, or when the processing unit 33 determines that the Find message has been tampered with, the processing unit 33 determines that the Find message received by the receiving unit 31 is inappropriate.

[0395] When the processing unit 33 determines that the Find message received by the receiving unit 31 is appropriate, the processing unit 33 stores the ECU identifier and the endpoint information obtained from the Find message in the storage unit 35 as client information. Also, the processing unit 33 outputs the Find message to the transmission unit 32.

[0396] The transmission unit 32 multicasts the Find message received from the processing unit 33 to a plurality of servers. For example, the transmission unit 32 refers to the connection destination list in the storage unit 35 and multicasts to a plurality of servers that can provide a service with a service ID of "0x0001".

[0397] On the other hand, when the processing unit 33 determines that the Find message received by the receiving unit 31 is inappropriate, the processing unit 33 outputs the Find message to the log generation unit 34.

[0398] The log generation unit 34 receives the Find message from the processing unit 33, obtains the ECU identifier included in the received Find message and a timestamp indicating the reception time, and writes the byte sequence of the Find message, the obtained ECU identifier, and the reception time to the unauthorized log list R11 in the storage unit 35 as an unauthorized log. After that, the log generation unit 34 discards the Find message.

[0399] (2-3) Transmission of Offer Message by Server Referring to FIG. 5 again, in in-vehicle ECU 111 which is a server, communication unit 11 receives a Find message from management device 201 and outputs the received Find message to processing unit 12.

[0400] Upon receiving the Find message from communication unit 11, processing unit 12 obtains the service ID from the received Find message. Processing unit 12 refers to the service list in storage unit 13 and determines whether the service indicated by the obtained service ID can be provided. If processing unit 12 determines that the service can be provided, it outputs a reply instruction to communication unit 11. On the other hand, if processing unit 12 determines that the service cannot be provided, it does not output a reply instruction.

[0401] Upon receiving the reply instruction from processing unit 12, communication unit 11 obtains the ECU identifier and the endpoint information of its own in-vehicle ECU 111 from storage unit 13. Then, communication unit 11 generates an Offer message including the ECU identifier and the endpoint information, and transmits the generated Offer message to management device 201.

[0402] (2-4) Judgment of the suitability of the Offer message by the management device Management device 201 determines the suitability of the Offer message received from the server in the same manner as described above in “(1-2) Judgment of the suitability of the Offer message by the management device”. If management device 201 determines that the Offer message is appropriate, it transmits the Offer message to the client.

[0403] (2-5) Transmission of the Subscribe message by the client Referring to FIG. 5 again, in-vehicle ECU 111 which is a client transmits a Subscribe message to management device 201 in the same manner as described above in “(1-3) Transmission of the Subscribe message by the client”.

[0404] (2-6) Decision on session establishment by the management device The management device 201 determines to establish a session in the same manner as described above in "(1-4) Determination of session establishment by the management device", generates a session key K, and distributes it to the server and the client.

[0405] (2-7) Distribution of session key by the management device The management device 201 distributes the session key K and the key ID to the server and the client participating in the session in the same manner as described above in "(1-5) Distribution of session key by the management device".

[0406] Also, the server and the client acquire the session key K in the same manner as described above in "(1-5) Distribution of session key by the management device".

[0407] (Communication in the session) The server and the client start a communication session using the session key K.

[0408] Specifically, in the server, the processing unit 12 encrypts a session message storing information to be provided as a service using the session key K in the storage unit 13, and outputs the encrypted session message to the communication unit 11. The communication unit 11 unicasts the session message received from the processing unit 12 to the client indicated by the endpoint information in the storage unit 13.

[0409] Also, in the client, the processing unit 12 decrypts the session message received from the server via the communication unit 11 using the session key K in the storage unit 13, and acquires information from the decrypted session message.

[0410] (Participation in an existing session) For example, even after starting a session with a certain client, the processing unit 12 in the server periodically or irregularly transmits an Offer message to the management device 201 via the communication unit 11.

[0411] After the establishment of a session between the server and the client, when the processing unit 33 in the management device 201 receives, via the receiving unit 31, a Subscribe message from another client in response to an Offer message from the server, it determines to establish a session between the server and the other client.

[0412] That is, for example, after distributing the session key K1 to the server S1 and the client C1, when the processing unit 33 receives, via the receiving unit 31, a Subscribe message from the client C2 in response to an Offer message from the server S1, it determines to establish a session between the server S1 and the client C2.

[0413] In this case, for example, the processing unit 33 generates a session key K2 different from the session key K1 distributed to the server S1 and the client C1 as the session key K for the session between the server S1 and the client C2, and distributes the generated session key K2 to the server S1 and the client C2.

[0414] That is, the processing unit 33 generates and distributes different session keys K for each combination of the server and the client.

[0415] (Multicast from Server to Client) In the in-vehicle system 302, the server is not limited to a configuration in which it unicasts session messages to clients. The server may be configured to multicast session messages to a plurality of clients.

[0416] More specifically, when the number of clients communicating in a session with one server reaches a predetermined number, the processing unit 33 in the management device 201 generates a session key KM, which is the session key K used for the session between the server and the plurality of clients, and distributes the generated session key KM to the server and the plurality of clients.

[0417] That is, when the processing unit 33 receives, via the receiving unit 31, a Subscribe message from the client C3 for the Offer message of the server S1 in a state where two sessions between the server S1 and the clients C1 and C2 are respectively established, the processing unit 33 generates a session key K3 to be used for the session between the server S1 and the client C3 and distributes it to the server S1 and the client C3. Further, the processing unit 33 further generates a session key KM to be used for the sessions between the server S1 and the clients C1, C2, and C3, and a multicast address based on the endpoint information of the server S1 and the clients C1, C2, and C3, and distributes the generated session key KM and the multicast address to the server S1 and the clients C1, C2, and C3.

[0418] When the server S1 and the clients C1, C2, and C3 acquire the session key KM and the multicast address, they start a communication session using the session key KM and the multicast address.

[0419] Referring again to FIG. 7, the server S1 has a session key K1 to be used for the session with the client C1, a session key K2 to be used for the session with the client C2, a session key K3 to be used for the session with the client C3, and a session key KM to be used for the session with the clients C1, C2, and C3. The client C1 is provided with the session keys K1 and KM. The client C2 has the session keys K2 and KM. The client C3 has the session keys K3 and KM.

[0420] In the server S1, the processing unit 12 encrypts a session message storing information to be provided as a service using the session key KM, and multicasts the encrypted session message to the clients C1, C2, and C3 via the communication unit 11.

[0421] For example, when the server S1 detects an abnormality in the in-vehicle system 302 while transmitting information to the clients C1, C2, and C3 by multicast, it switches to a state of transmitting information to the plurality of clients C1, C2, and C3 by unicast.

[0422] As an example, consider a case where a malicious device that has hijacked the client C1 impersonates the server S1 and multicasts a session message encrypted using the session key KM to the server S1 and the clients C2 and C3.

[0423] When the processing unit 12 in the server S1 receives a session message from the malicious device via the communication unit 11, since it has received the session message despite being the sender of the session message, it determines that an abnormality has occurred in the in-vehicle system 302.

[0424] In this case, the processing unit 12 in the server S1 switches the transmission of the session message from multicast to unicast. Specifically, the processing unit 12 unicasts a session message encrypted using the session key K1 to the client C1 via the communication unit 11, unicasts a session message encrypted using the session key K2 to the client C2 via the communication unit 11, and unicasts a session message encrypted using the session key K3 to the client C3 via the communication unit 11.

[0425] (Termination of Session from Client Side) In the client, when the processing unit 12 stops receiving the service, it encrypts a StopSubscribe message including the service ID using the session key K in the storage unit 13 and transmits it to the management device 201 via the communication unit 11. Also, the processing unit 12 discards the session key K and the server endpoint information in the storage unit 13.

[0426] Referring to FIG. 16 again, in the management device 201, the receiving unit 31 receives a StopSubscribe message from the client. The receiving unit 31 attaches a timestamp to the received StopSubscribe message and outputs it to the processing unit 33. The StopSubscribe message from the client received by the receiving unit 31 is an example of an end request.

[0427] Upon receiving the StopSubscribe message from the receiving unit 31, the processing unit 33 outputs the received StopSubscribe message to the transmitting unit 32. Also, the processing unit 33 notifies the log generation unit 34 of the reception time te indicated by the timestamp attached to the StopSubscribe message.

[0428] Based on the reception of the StopSubscribe message by the receiving unit 31, the transmitting unit 32 transmits a StopSubscribe message for ending the session to other in-vehicle ECUs 111 participating in the session, that is, to the server. More specifically, the transmitting unit 32 transmits the StopSubscribe message received from the processing unit 33 to the server. The StopSubscribe message transmitted to the server by the transmitting unit 32 is an example of an end instruction.

[0429] Referring to FIG. 16 again, upon receiving the notification of the reception time te from the processing unit 33, the log generation unit 34 writes the notified reception time te as the "end time" of the session log into the session log list R12.

[0430] In the server, the processing unit 12 receives a StopSubscribe message from the management device 201 via the communication unit 11, and decrypts the received StopSubscribe message using the session key K in the storage unit 13. The processing unit 12 discards the session key K and the client's endpoint information in the storage unit 13.

[0431] (End of session from the server side) On the server, when the processing unit 12 stops providing the service, it encrypts the StopOffer message including the service ID using the session key K in the storage unit 13 and transmits it to the management device 201 via the communication unit 11. Also, the processing unit 12 discards the session key K and the client's endpoint information in the storage unit 13.

[0432] Referring again to FIG. 16, in the management device 201, the receiving unit 31 Server receives a StopOffer message from. The receiving unit 31 attaches a timestamp to the received StopOffer message and outputs it to the processing unit 33. The StopOffer message from the server received by the receiving unit 31 is an example of an end request.

[0433] Upon receiving the StopOffer message from the receiving unit 31, the processing unit 33 outputs the received StopOffer message to the transmitting unit 32. Also, the processing unit 33 notifies the log generation unit 34 of the reception time te indicated by the timestamp attached to the StopOffer message.

[0434] Upon receiving the StopOffer message by the receiving unit 31, the transmitting unit 32 transmits a StopOffer message indicating that the session should be terminated to other in-vehicle ECUs 111, i.e., clients, participating in the session. More specifically, the transmitting unit 32 transmits the StopOffer message received from the processing unit 33 to the client. The StopOffer message to the client transmitted by the transmitting unit 32 is an example of an end instruction.

[0435] Referring again to FIG. 6, upon receiving the notification of the reception time te from the processing unit 33, the log generation unit 34 writes the notified reception time te as the "end time" of the session log in the session log list R12.

[0436] At the client, the processing unit 12 receives a StopOffer message from the management device 201 via the communication unit 11, and decrypts the received StopOffer message using the session key K in the storage unit 13. The processing unit 12 discards the session key K and the server endpoint information in the storage unit 13.

[0437] [Operation flow] FIG. 17 is a flowchart defining an example of an operation procedure when the management device according to the second embodiment of the present disclosure distributes a session key.

[0438] Referring to FIG. 17, first, the management device 201 waits for an Offer message from the server, a Find message from the client, or a Subscribe message from the client (NO in step S502).

[0439] Next, when the management device 201 receives an Offer message from the server or a Find message from the client (YES in step S502 and YES in step S504), it determines the suitability of the received message (step S506).

[0440] Next, when the management device 201 determines that the received message is inappropriate (NO in step S508), it acquires the ECU identifier included in the message and a timestamp indicating the reception time, and writes the byte sequence of the message, the acquired ECU identifier, and the reception time as an illegal log to the illegal log list R11 (step S510).

[0441] Next, the management device 20 discards the message (step S512) and waits for a new message from the server or the client (NO in step S502).

[0442] On the other hand, when the management device 201 determines that the received message is appropriate (YES in step S508), the management device multicasts the message. More specifically, when the message is an Offer message, the management device 201 multicasts the message to a plurality of clients, and when the message is a Find message, the management device 201 multicasts the message to a plurality of servers (step S51 4 ).

[0443] On the other hand, when the management device 201 receives a Subscribe message from a client (YES in step S502 and NO in step S504), the management device 201 determines to establish a session between the server and the client, and generates a session key K and a key ID to be used for the session (step S516).

[0444] Next, the management device 201 encrypts the session key K. More specifically, the management device 201 generates an encryption key KS by encrypting the session key K using the unique ID of the server as an encryption key. Also, the management device 201 generates an encryption key KC by encrypting the session key K using the unique ID of the client as an encryption key (step S518).

[0445] Next, the management device 201 calculates a hash value (step S520).

[0446] More specifically, the management device 201 includes the encryption key KS in the Subscribe message, and gives the Subscribe message and the unique ID of the server to a predetermined hash function to calculate a hash value HVS. Also, the management device 201 generates a start message MC including the encryption key KC, and gives the generated start message MC and the unique ID of the client to a predetermined hash function to calculate a hash value HVC.

[0447] Next, the management device 201 transmits the session key K and the hash value. More specifically, the management device 201 transmits a Subscribe message including the encryption key KS and the hash value HVS to the server, and transmits a start message MC including the encryption key KC and the hash value HVC to the client (step S522).

[0448] Next, the management device 201 writes the service ID of the service provided in the session to be established, the ECU identifier of each of the server and the client which is the destination of the session key K, and the start time of the session, as "Service ID", "ECU Identifier", and "Start Time" of the session log, respectively, in the session log list R12 (step S524).

[0449] Next, the management device 201 waits for a new Offer message from the server, a new Find message from the client, or a new Subscribe message from the client (NO in step S502).

[0450] FIG. 18 is a diagram showing an example of a communication sequence in an in-vehicle system according to a second embodiment of the present disclosure.

[0451] Referring to FIG. 18, first, the server S1 transmits an Offer message to the management device 201 (step S602).

[0452] Next, the management device 201 determines the propriety of the Offer message received from the server S1 (step S604).

[0453] Next, when the management device 201 determines that the Offer message is appropriate, the management device 201 multicasts the Offer message to the clients C1, C2 (step S606).

[0454] Next, for example, client C1 obtains the service ID from the Offer message received from the management device 201, determines that the service indicated by the obtained service ID is required, and transmits a Subscribe message to the management device 201 (step S608).

[0455] Next, the management device 201 receives the Subscribe message from the client C1, decides to establish a session between the server S1 and the client C1, and generates a session key K1 to be used for the session (step S610). Also, at this time, the management device 201 writes the service ID of the service provided in the session to be established, the ECU identifiers of the server S1 and the client C1, and the start time of the session, as "Service ID", "ECU Identifier", and "Start Time" of the session log, respectively, to the session log list R12.

[0456] Next, the management device 201 distributes the generated session key K1 to the server S1 by including it in the Subscribe message (step S612). Also, the management device 201 distributes the generated session key K1 to the client C1 by including it in the start message MC (step S614).

[0457] Next, the server S1 unicasts a session message encrypted using the session key K1 to the client C1, for example, periodically (step S616).

[0458] Next, for example, client C2 obtains the service ID from the Offer message received from the management device 201, determines that the service indicated by the obtained service ID is required, and transmits a Subscribe message to the management device 201 (step S618).

[0459] Next, the management device 201 receives a Subscribe message from the client C2, determines to establish a session between the server S1 and the client C2, and generates a session key K2 to be used for the session (step S620). At this time, the management device 201 writes the service ID of the service provided in the established session, the ECU identifiers of the server S1 and the client C2, and the start time of the session into the session log list R12 as the "service ID", "ECU identifier", and "start time" of the session log, respectively.

[0460] Next, the management device 201 distributes the generated session key K2 to the server S1 by including it in the Subscribe message (step S622). Further, the management device 201 distributes the generated session key K2 to the client C2 by including it in the start message MC (step S624).

[0461] Next, the server S1 unicasts a session message encrypted using the session key K1 to the client C1, for example, periodically (step S626).

[0462] Also, the server S1 unicasts a session message encrypted using the session key K2 to the client C2, for example, periodically (step S628).

[0463] Next, for example, the client C1 sends a StopSubscribe message to the management device 201 to stop receiving the service (step S630).

[0464] Next, the management device 201 receives the StopSubscribe message from the client C1 and sends the StopSubscribe message to the server S1 (step S632). At this time, the management device 201 writes the end time of the session into the session log list R12 as the "end time" of the session log.

[0465] Next, the client C1 discards the session key K1 and the endpoint information of the server S1 in the storage unit 13 (step S634).

[0466] Also, the server S1 discards the session key K1 and the endpoint information of the client C1 in the storage unit 13 (step S636).

[0467] Next, the server S1 continues to unicast the session message to the client C2 (step S638).

[0468] FIG. 19 is a diagram showing another example of a communication sequence in an in-vehicle system according to the second embodiment of the present disclosure.

[0469] Referring to FIG. 19, first, the client C1 transmits a Find message to the management device 201 (step S702).

[0470] Next, the management device 201 determines the propriety of the Find message received from the client C1 (step S704).

[0471] Next, when the management device 201 determines that the Find message is appropriate, the management device 201 multicasts the Find message to the servers S1 and S2 (step S706).

[0472] Next, for example, the server S1 obtains the service ID from the Find message received from the management device 201, determines that the service indicated by the obtained service ID can be provided, and transmits an Offer message to the management device 201 (step S708).

[0473] Next, the management device 201 determines the propriety of the Offer message received from the server S1 (step S710).

[0474] Next, when the management device 201 determines that the Offer message is appropriate, it sends the Offer message to the client C1 (step S712).

[0475] Next, the client C1 receives the Offer message from the management device 201 and sends a Subscribe message to the management device 201 (step S714).

[0476] Next, the management device 201 receives the Subscribe message from the client C1, determines to establish a session between the server S1 and the client C1, and generates a session key K3 to be used for the session (step S716). Also, at this time, the management device 201 writes the service ID of the service provided in the established session, the ECU identifiers of the server S1 and the client C1, and the start time of the session as the "service ID", "ECU identifier", and "start time" of the session log, respectively, in the session log list R12.

[0477] Next, the management device 201 distributes the generated session key K1 to the client C1 by including it in the start message MC (step S718). Also, the management device 201 distributes the generated session key K3 to the server S1 by including it in the Subscribe message (step S720).

[0478] Next, the server S1 unicasts a session message encrypted using the session key K3 to the client C1, for example, periodically (step S722).

[0479] Next, for example, the server S1 sends a StopOffer message to the management device 201 to stop providing the service (step S724).

[0480] Next, the management device 201 receives a StopOffer message from the server S1 and transmits the StopOffer message to the client C1 (step S726). At this time, the management device 201 writes the end time of the session as the "end time" of the session log to the session log list R12.

[0481] Next, the server S1 discards the session key K3 and the endpoint information of the client C1 in the storage unit 13 (step S728).

[0482] Also, the client C1 discards the session key K3 and the endpoint information of the server S1 in the storage unit 13 (step S730).

[0483] Note that in step S724 in FIG. 19, instead of the server S1 transmitting a StopOffer message to the management device 201, the client C1 may transmit a StopSubscribe message to the management device 201. Also, in step S630 in FIG. 18, instead of the client C1 transmitting a StopSubscribe message to the management device 201, the server S1 may transmit a StopOffer message to the management device 201. In this case, the management device 201 transmits the StopOffer message to the clients C1 and C2.

[0484] Note that in the in-vehicle system 302 according to the second embodiment of the present disclosure, in a state where the server transmits information to a plurality of clients by multicast, when an abnormality in the in-vehicle system 302 is detected, it is configured to switch to a state of transmitting information to a plurality of clients by unicast, but the present disclosure is not limited to this. The server may be configured not to switch to a state of transmitting information to a plurality of clients by unicast. Also, the server may be configured to be able to transmit information by multicast while transmitting information to a plurality of clients by unicast and not be able to transmit information by multicast.

[0485] Also, in the management device 201 according to the second embodiment of the present disclosure, although the processing unit 33 is configured to output a Subscribe message including the encryption key KS and a start message MC including the encryption key KC to the transmission unit 32, the present disclosure is not limited thereto. The processing unit 33 may be configured to output a Subscribe message and a start message MC including an unencrypted session key K to the transmission unit 32. In this case, the transmission unit 32 transmits the Subscribe to the server and transmits the start message MC to the client.

[0486] Also, in the management device 201 according to the second embodiment of the present disclosure, although the transmission unit 32 is configured to transmit the hash value HVS to the server and transmit the hash value HVC to the client, the present disclosure is not limited thereto. The transmission unit 32 may be configured not to transmit the hash value HVS while transmitting the Subscribe message to the server. Also, the transmission unit 32 may be configured not to transmit the hash value HVC while transmitting the start message MC to the client.

[0487] Also, in the management device 201 according to the second embodiment of the present disclosure, although the reception unit 31 is configured to receive a StopSubscribe message from the client and receive a StopOffer message from the server, the present disclosure is not limited thereto. The reception unit 31 may be configured not to receive the StopSubscribe message and the StopOffer message. In this case, for example, in the in-vehicle system 302, instead of transmitting the StopSubscribe message to the management device 201, the client transmits the StopSubscribe message to the server. Also, instead of transmitting the StopOffer message to the management device 201, the server transmits the StopOffer message to the client.

[0488] Also, although the management device 201 according to the second embodiment of the present disclosure is configured to include a log generation unit 34, the present disclosure is not limited thereto. The management device 201 may be configured not to include the log generation unit 34.

[0489] Also, in the management device 201 according to the second embodiment of the present disclosure, although the log generation unit 34 is configured to write the start time and end time of the session to the session log list R12, the present disclosure is not limited thereto. The log generation unit 34 may be configured not to write the start time and end time of the session to the session log list R12 while writing the service ID of the service provided in the session, the ECU identifier of the server that is the destination of the Subscribe message, and the ECU identifier of the client that is the destination of the start message MC to the session log list R12.

[0490] Also, in the management device 201 according to the second embodiment of the present disclosure, although the processing unit 33 is configured to generate a session key K with random content for each session, the present disclosure is not limited thereto. The processing unit 33 may be configured to generate a session key K with regular content for each session.

[0491] Also, in the management device 201 according to the second embodiment of the present disclosure, the processing unit 33 may be configured to further determine the propriety of the Subscribe message, may be configured to further determine the propriety of the StopSubscribe message, or may be configured to further determine the propriety of the StopOffer message, similar to the processing unit 23 in the relay device 101 according to the first embodiment.

[0492] By the way, a technology capable of further improving the security in the in-vehicle network is desired. More specifically, for example, in an in-vehicle system that performs service-oriented communication, a technology capable of further improving the security in the in-vehicle network is desired.

[0493] In contrast, in the management device 201 according to the second embodiment of the present disclosure, the receiving unit 31 receives an Offer message from the server. Further, the receiving unit 31 receives a Subscribe message from the client. The processing unit 33 generates a session key K unique to the session used for the session associated with the Offer message and the Subscribe message received by the receiving unit 31. The transmitting unit 32 transmits the session key generated by the processing unit 33 to the server and the client participating in the session.

[0494] In this way, by receiving an Offer message from the server, receiving a Subscribe message from the client, generating a session key K unique to the session, and transmitting it to the server and the client, communication using an individual session key K can be performed for each session between the server and the client, so that the security of communication between the server and the client can be improved. Further, for example, by authenticating the server that is the source of the Offer message and the client that is the source of the Find message, Offer messages and Find messages from unauthorized devices can be detected. Therefore, the security in the in-vehicle network can be further improved.

[0495] Further, in the management device 201, when the number of clients communicating with one server in a session reaches a predetermined number, the processing unit 33 generates a session key KM for the session between the server and the plurality of clients, and distributes the generated session key KM to the server and the plurality of clients. With this configuration, multicast communication using the session key KM can be performed between the server and the plurality of clients. Therefore, the security in the in-vehicle network where messages conforming to SOME / IP are transmitted and received can be improved.

[0496] The above-described embodiments should be considered illustrative in all respects and not restrictive. The scope of the present invention is indicated by the scope of claims rather than the above description, and it is intended that all modifications within the meaning and scope equivalent to the scope of claims be included.

[0497] The above description includes the features appended below. [Appendix 1] A relay unit that performs relay processing for transmitting each of a plurality of frames received from a plurality of in-vehicle devices to the in-vehicle device of the destination; A determination unit that determines that the plurality of frames include a start request for a communication session between the plurality of in-vehicle devices and include a start response to the start request; A generation unit that generates a common key for each session used in the session in which the in-vehicle device that is the transmission source of the frame determined by the determination unit to include the start request and one or a plurality of the in-vehicle devices that are the transmission sources of the frames determined by the determination unit to include the start response participate; A transmission unit that transmits the common key to each in-vehicle device participating in the session via the relay unit, The relay unit receives a first frame including a service ID, endpoint information of the in-vehicle device that is the transmission source of the start request, and an ECU identifier of the in-vehicle device that is the transmission source of the start request; The generation unit determines the suitability of the first frame based on the service ID, the endpoint information, and the ECU identifier; The relay unit receives a second frame including a service ID, endpoint information of the in-vehicle device that is the transmission source of the start response, and an ECU identifier of the in-vehicle device that is the transmission source of the start response; The generation unit determines the suitability of the second frame based on the service ID, the endpoint information, and the ECU identifier, an in-vehicle relay device.

[0498] [Appendix 2] A plurality of in-vehicle devices; An in-vehicle relay device, The in-vehicle relay device performs relay processing for transmitting a plurality of frames respectively received from the plurality of in-vehicle devices to the in-vehicle device of the destination. A first in-vehicle device, which is one of the plurality of in-vehicle devices, transmits a first frame including a start request for a communication session between the plurality of in-vehicle devices to the in-vehicle relay device. A second in-vehicle device, which is one of the plurality of in-vehicle devices, transmits a second frame including a start response to the start request to the in-vehicle relay device. The in-vehicle relay device generates a common key for each session used in the session in which the first in-vehicle device that is the transmission source of the received first frame and the second in-vehicle device that is the transmission source of the received second frame participate, and transmits the generated common key to each in-vehicle device participating in the session. The first in-vehicle device transmits the first frame including a service ID, endpoint information of the first in-vehicle device, and an ECU identifier of the first in-vehicle device to the in-vehicle relay device. The in-vehicle relay device determines the suitability of the first frame based on the service ID, the endpoint information, and the ECU identifier. The second in-vehicle device transmits the second frame including a service ID, endpoint information of the second in-vehicle device, and an ECU identifier of the second in-vehicle device to the in-vehicle relay device. The in-vehicle relay device determines the suitability of the second frame based on the service ID, the endpoint information, and the ECU identifier. An in-vehicle system.

[0499] [Appendix 3] A management device used in an in-vehicle system including a plurality of in-vehicle devices, a receiving unit that receives from the in-vehicle device a start request for a communication session between some or all of the plurality of in-vehicle devices; a generating unit that generates a common key unique to the session, which is used in the session associated with the start request; A transmission unit that transmits the common key to each in-vehicle device participating in the session. The receiving unit receives the start request including a service ID, endpoint information of the in-vehicle device that is the source of the start request, and an ECU identifier of the in-vehicle device that is the source of the start request. The generation unit is a management device that determines the propriety of the start request based on the service ID, the endpoint information, and the ECU identifier.

[0500] [Appendix 4] A plurality of in-vehicle devices, and a management device. The in-vehicle device transmits a start request for a session of communication between a plurality of the in-vehicle devices that are part or all of the plurality of in-vehicle devices to the management device. The management device generates a common key unique to the session to be used for the session associated with the received start request, and transmits the generated common key to each in-vehicle device participating in the session. The in-vehicle device transmits the start request including a service ID, its own endpoint information, and its own ECU identifier to the management device. The management device is an in-vehicle system that determines the propriety of the start request based on the service ID, the endpoint information, and the ECU identifier.

Explanation of Signs

[0501] 1 Vehicle 11 Communication unit 12 Processing unit 13 Storage unit 14 Cable 21 Communication port 22 Relay unit 23 Processing unit (judgment unit, generation unit, transmission unit) 24 Log generation unit (recording unit) 25 Storage unit 31 Receiving unit 32 Transmission unit 33 Processing unit 34 Log generation unit 35 Storage unit 101 Relay device (in-vehicle relay device) 102 Relay device 111 In-vehicle ECU (in-vehicle device) 201 Management device 301, 302 In-vehicle system R1, R11 Illegal log list R2, R12 Session log list S1 Server C1, C2, C3 Client

Claims

1. A relay unit that performs relay processing for transmitting a plurality of frames received from a plurality of in-vehicle devices to the in-vehicle device of the destination respectively; A determination unit that determines that the plurality of frames include a start request for a communication session between the plurality of in-vehicle devices and include a start response to the start request; A generation unit that generates a common key for a session in which the in-vehicle device that is the transmission source of the frame determined by the determination unit to include the start request and one or a plurality of the in-vehicle devices that are the transmission sources of the frames determined by the determination unit to include the start response participate, for each session; An in-vehicle relay device comprising: a transmission unit that transmits the common key to each in-vehicle device participating in the session via the relay unit.

2. The in-vehicle relay device further comprises: A storage unit that stores the unique ID of each in-vehicle device; The in-vehicle relay device according to claim 1, wherein the transmission unit transmits, via the relay unit, the common key encrypted using one of the unique IDs as an encryption key to the in-vehicle device having the unique ID used for encryption.

3. The in-vehicle relay device according to claim 2, wherein the transmission unit further transmits, via the relay unit, a hash value calculated using one of the unique IDs and the common key to the in-vehicle device having the unique ID used for calculation of the hash value.

4. The in-vehicle relay device further comprises: A recording unit that records session information regarding the session in which the common key is used, according to any one of claims 1 to 3.

5. The in-vehicle relay device according to claim 4, wherein the recording unit records, as the session information, the transmission time of the common key by the relay unit.

6. The determination unit determines that the frame received by the relay unit includes an end request for the session; The in-vehicle relay device according to claim 4 or claim 5, wherein the recording unit records, as the session information, the reception time of the frame including the end request by the relay unit.

7. The determination unit determines the propriety of the frame according to a determination result that the frame received by the relay unit includes the start request or the start response. The relay unit performs the relay process or discarding of the frame according to the determination result of the suitability of the frame by the determination unit, the in-vehicle relay device according to any one of claims 1 to 6.

8. A management device used in an in-vehicle system including a plurality of in-vehicle devices, a receiving unit that receives, from a plurality of the in-vehicle devices, a start request for a communication session between some or all of the plurality of in-vehicle devices, and a start response to the start request, a generating unit that generates a common key unique to the session, which is used for the session associated with the start request and the start response, a management device including a transmitting unit that transmits the common key to each of the in-vehicle devices participating in the session.

9. The management device further includes a storage unit that stores the unique ID of each in-vehicle device, The transmitting unit according to claim 8, wherein the transmitting unit transmits the common key encrypted using one of the unique IDs as an encryption key to the in-vehicle device having the unique ID used for the encryption.

10. The transmitting unit according to claim 9, wherein the transmitting unit further transmits a hash value calculated using one of the unique IDs and the common key to the in-vehicle device having the unique ID used for the calculation of the hash value.

11. The receiving unit receives an end request for the session from the in-vehicle device, The transmitting unit according to any one of claims 8 to 10, wherein the transmitting unit transmits an end instruction to end the session to the other in-vehicle devices participating in the session based on the reception of the end request by the receiving unit.

12. The management device further includes a recording unit that records session information regarding the session in which the common key is used, the management device according to any one of claims 8 to 11.

13. The recording unit according to claim 12, wherein the recording unit records, as the session information, the transmission time of the common key by the transmitting unit.

14. The management device further includes a recording unit that records session information regarding the session in which the common key is used, The recording unit according to claim 11, wherein the recording unit records, as the session information, the reception time of the end request by the receiving unit.

15. a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, an in-vehicle relay device, The in-vehicle relay device performs a relay process of transmitting a plurality of frames respectively received from the plurality of in-vehicle devices to the in-vehicle device of the destination, The first in-vehicle device transmits a first frame including a start request for a communication session among a plurality of the in-vehicle devices that are part or all of the plurality of in-vehicle devices to the in-vehicle relay device, The second in-vehicle device transmits a second frame including a start response to the start request to the in-vehicle relay device, The in-vehicle relay device generates a common key for each session used in the session in which the first in-vehicle device that is the transmission source of the received first frame and the second in-vehicle device that is the transmission source of the received second frame participate, and transmits the generated common key to each in-vehicle device participating in the session. An in-vehicle system.

16. The in-vehicle relay device, the first in-vehicle device, and the second in-vehicle device are connected without passing through another relay device. The in-vehicle system according to claim 15.

17. When the in-vehicle device detects an abnormality in the in-vehicle system while transmitting information to a plurality of the in-vehicle devices by multicast, it switches to a state of transmitting information to the plurality of in-vehicle devices by unicast. The in-vehicle system according to claim 15 or claim 16.

18. The in-vehicle relay device includes a storage unit that stores the unique ID of each in-vehicle device in the in-vehicle system, The in-vehicle relay device further transmits a hash value calculated using one of the unique IDs and the common key to the in-vehicle device having the unique ID used for calculating the hash value, The in-vehicle device collates a hash value calculated using the common key received from the in-vehicle relay device and its own unique ID with the hash value received from the in-vehicle relay device. The in-vehicle system according to any one of claims 15 to 17.

19. A plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, And a management device, The first in-vehicle device transmits a start request for a communication session among a plurality of the in-vehicle devices that are part or all of the plurality of in-vehicle devices to the management device, The second in-vehicle device transmits a start response to the start request to the management device, The in-vehicle system, wherein the management device generates a common key unique to the session for use in the session associated with the received start request and the start response, and transmits the generated common key to each in-vehicle device participating in the session.

20. The in-vehicle system according to claim 19, wherein, when detecting an abnormality in the in-vehicle system while the in-vehicle device is transmitting information to a plurality of the in-vehicle devices by multicast, the in-vehicle device switches to a state of transmitting information to the plurality of the in-vehicle devices by unicast.

21. The management device includes a storage unit that stores unique IDs of the respective in-vehicle devices in the in-vehicle system. The management device further transmits a hash value calculated using one of the unique IDs and the common key to the in-vehicle device having the unique ID used for calculating the hash value. The in-vehicle system according to claim 19 or claim 20, wherein the in-vehicle device collates a hash value calculated using the common key received from the management device and its own unique ID with the hash value received from the management device.

22. A communication management method in an in-vehicle relay device that performs relay processing for transmitting a plurality of frames received from a plurality of in-vehicle devices to the in-vehicle device of the destination, respectively, comprising: a step of determining that the plurality of frames include a start request for a session of communication between the plurality of in-vehicle devices and a start response to the start request; a step of generating, for each session, a common key for use in the session in which the in-vehicle device that is the transmission source of the frame determined to include the start request and one or a plurality of the in-vehicle devices that are the transmission sources of the frames determined to include the start response participate; and a step of transmitting the generated common key to each in-vehicle device participating in the session.

23. A communication management method in a management device used in an in-vehicle system including a plurality of in-vehicle devices, comprising: a step of receiving, from a plurality of the in-vehicle devices, a start request for a session of communication between some or all of the plurality of in-vehicle devices and a start response to the start request; a step of generating a common key unique to the session for use in the session associated with the received start request and the start response. A communication management method including the step of transmitting the generated common key to each in-vehicle device participating in the session.

24. A communication management method in an in-vehicle system including a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, and an in-vehicle relay device that performs relay processing for transmitting a plurality of frames received from the plurality of in-vehicle devices to the in-vehicle device of the destination, respectively, The step of the first in-vehicle device transmitting a first frame including a start request for a communication session between a plurality of the in-vehicle devices that are some or all of the plurality of in-vehicle devices to the in-vehicle relay device, The step of the second in-vehicle device transmitting a second frame including a start response to the start request to the in-vehicle relay device, A communication management method including the step of the in-vehicle relay device generating a common key for each session used in the session in which the first in-vehicle device that is the transmission source of the received first frame and the second in-vehicle device that is the transmission source of the received second frame participate, and transmitting the generated common key to each in-vehicle device participating in the session.

25. A communication management method in an in-vehicle system including a plurality of in-vehicle devices including a first in-vehicle device and a second in-vehicle device, and a management device, The step of the first in-vehicle device transmitting a start request for a communication session between a plurality of the in-vehicle devices that are some or all of the plurality of in-vehicle devices to the management device, The step of the second in-vehicle device transmitting a start response to the start request to the management device, A communication management method including the step of the management device generating a common key unique to the session used in the session associated with the received start request and the start response, and transmitting the generated common key to each in-vehicle device participating in the session.

Images