JP7328419B2 - In-vehicle communication system, in-vehicle communication device, computer program and communication method - Google Patents

Description

The present invention relates to an in-vehicle communication system, an in-vehicle communication device, a computer program, and a communication method in which a plurality of devices mounted on a vehicle communicate.

BACKGROUND ART In recent years, technologies such as automatic driving and driving assistance of vehicles have been researched and developed, and advanced functions of vehicles are being promoted. 2. Description of the Related Art As vehicles become more sophisticated, hardware and software in devices such as ECUs (Electronic Control Units) installed in vehicles become more sophisticated and complicated. On the other hand, there is the problem that attacks such as vehicle hijacking can be carried out by injecting unauthorized devices or software into vehicle systems. In order to prevent unauthorized attacks on vehicles, various countermeasures such as communication encryption are being considered.

In Patent Document 1, a plurality of ECUs and a monitoring device are connected to a common CAN (Controller Area Network) bus, each ECU outputs a transmission frame with authentication information to the CAN bus, and the monitoring device connects to the CAN bus. A communication system is described that determines whether or not authentication information in a frame output to a bus is correct, and causes an ECU to discard a frame whose authentication information is determined to be incorrect.

JP 2016-21623 A

As in the communication system described in Patent Document 1, each device connected to a common communication line sends a message with information such as an authenticator attached to it, which is effective in improving security performance. However, it is expected that the security level required for each device will differ as the number of devices mounted on the vehicle increases and sophisticates. Until now, the situation where multiple devices with different security levels coexist in a vehicle was not envisioned.

The present invention has been made in view of such circumstances, and an object thereof is to provide an in-vehicle communication system and an in-vehicle communication device that enable a plurality of devices with different security levels to coexist. , to provide a computer program and a communication method.

An in-vehicle communication system according to this aspect includes a plurality of in-vehicle communication devices connected to a common communication line, and an in-vehicle communication control device connected to the common communication line and performing control related to communication of the plurality of in-vehicle communication devices. wherein a cryptographic key is determined for each of the in-vehicle communication devices, and the in-vehicle communication device includes a first storage unit that stores the cryptographic key determined for itself; a first authenticator generating unit for generating an authenticator attached to a message to be transmitted using an encryption key stored in a storage unit; The in-vehicle communication control device includes a second storage unit that stores the encryption key of each in-vehicle communication device, and a second storage unit that stores the encryption key of each in-vehicle communication device. a second authenticator determining unit for determining whether the received authenticator is correct or not by using the corresponding encryption key stored in the second storage unit; and authentication attached to the message received by the second authenticator determining unit. a second authenticator generating unit for generating another authenticator using an encryption key different from the encryption key used to determine the authenticator when the child is determined to be correct; and a relay unit that relays message transmission/reception between in-vehicle communication devices having different security levels by attaching another authenticator generated by the second authenticator generation unit and transmitting the message.

The present application can be realized not only as an in-vehicle communication control device or an in-vehicle communication device having such a characteristic processing unit, but also as a communication control method or a communication method having such characteristic processing as steps. Alternatively, it can be implemented as a computer program for causing a computer to execute such steps. Moreover, it can be realized as a semiconductor integrated circuit that realizes part or all of the vehicle-mounted communication control device or the vehicle-mounted communication device, or can be realized as another device or system including the vehicle-mounted communication control device or the vehicle-mounted communication device.

According to the above, it is possible for a plurality of devices with different security levels to coexist.

1 is a schematic diagram for explaining an outline of an in-vehicle communication system according to an embodiment; FIG. 1 is a schematic diagram for explaining an outline of an in-vehicle communication system according to an embodiment; FIG. It is a schematic diagram which shows an example of message transmission/reception by DC and ECU. It is a schematic diagram which shows an example of the notification from DC to ECU. 3 is a block diagram showing the configuration of a DC according to this embodiment; FIG. 4 is a schematic diagram showing an example of information about encryption keys stored in a table; FIG. 2 is a block diagram showing the configuration of an ECU according to this embodiment; FIG. FIG. 10 is a schematic diagram for explaining transmission timing of notification messages of DCs; 4 is a flowchart showing a procedure of message reception processing performed by an ECU according to the present embodiment; 5 is a flow chart showing the procedure of a keep-alive signal transmission process performed by an ECU according to the present embodiment; FIG. 10 is a flow chart showing a procedure of notification message transmission processing performed by a DC according to the present embodiment; FIG. FIG. 10 is a flow chart showing a procedure of notification message transmission processing performed by a DC according to the present embodiment; FIG. FIG. 9 is a schematic diagram showing an example of message transmission/reception by a DC and an ECU according to Embodiment 2; FIG. 10 is a flow chart showing a procedure of processing performed by a DC according to Embodiment 2; FIG. FIG. 11 is a schematic diagram showing an example of message transmission/reception by a DC and an ECU according to Embodiment 3; FIG. 12 is a schematic diagram for explaining message discarding by a DC according to the third embodiment; 13 is a flow chart showing a procedure of processing performed by a DC according to Embodiment 3;

[Description of the embodiment of the present invention]
First, embodiments of the present invention will be listed and described. Moreover, at least part of the embodiments described below may be combined arbitrarily.

(1) An in-vehicle communication system according to this aspect includes a plurality of in-vehicle communication devices connected to a common communication line, and an in-vehicle communication device connected to the common communication line and controlling communication of the plurality of in-vehicle communication devices. and a communication control device, wherein the plurality of on-vehicle communication devices are classified into a plurality of security levels, a common key is determined for each security level, and the on-vehicle communication device controls its own security. a first storage unit for storing a common key corresponding to a level; a first authenticator generating unit for generating an authenticator attached to a message to be transmitted using the common key stored in the first storage unit; a first authenticator determination unit that determines whether the authenticator attached to the received message is correct or not using the common key stored in the first storage unit; a second storage unit that stores a common key; a second authenticator determination unit that determines whether an authenticator attached to a received message is correct using the corresponding common key stored in the second storage unit; An in-vehicle communication device that does not store the common key used by the second authenticator determination unit in the determination when the second authenticator determination unit determines that the authenticator attached to the received message is not correct. and a second notification unit that notifies to.

In this aspect, the vehicle-mounted communication control device and the plurality of vehicle-mounted communication devices are connected to the common communication line. A plurality of in-vehicle communication devices are classified into a plurality of security levels, and a common key is determined for each security level. Each in-vehicle communication device stores a common key corresponding to its own security level, attaches an authenticator generated using the stored common key to a message, transmits the message, and receives an authentication attached to the received message. Judge whether the child is right or wrong. Since messages with authenticators generated using different common keys are sent and received over a common communication line, each in-vehicle communication device is attached with an authenticator generated with the same common key as its own common key. However, it is not possible to judge the correctness of a message attached with an authenticator generated with a common key different from its own common key.
The in-vehicle communication control device stores a common key for each security level, and makes determination using the common key corresponding to the authenticator attached to the received message. Therefore, the in-vehicle communication control device can determine whether the authenticators attached to all messages transmitted and received via the common communication line are correct. When receiving a message to which an incorrect authenticator is attached, the in-vehicle communication control device notifies the in-vehicle communication device that does not store the common key used to determine the authenticator.
As a result, each in-vehicle communication device judges by itself if the authenticity of the authenticator can be judged by the common key stored by itself, and receives notification from the in-vehicle communication control device for messages that cannot be judged by itself. Since it can be determined that an incorrect message has been sent to a common communication line, it is possible to mix in-vehicle communication devices with different security levels.

(2) It is possible to attach a plurality of authenticators to a message, and the vehicle-mounted communication device has a common key determined for its own security level and a common key determined for a security level lower than the security level. and the common key stored in the first storage unit, and the first authenticator generation unit uses the one or more common keys stored in the first storage unit to create a message to be sent. Alternatively, it is preferable to generate a plurality of authenticators.

In this aspect, it is possible to attach a plurality of authenticators to the message. The vehicle-mounted communication device stores a common key defined for its own security level and a common key defined for a security level lower than its own security level. An in-vehicle communication device that stores a plurality of common keys generates a plurality of authenticators using the plurality of common keys, attaches the generated plurality of authenticators to a message, and transmits the message. This allows the vehicle-mounted communication device to transmit messages to vehicle-mounted communication devices with the same security level as itself and to vehicle-mounted communication devices with a lower security level.

(3) The first authenticator determination unit of the in-vehicle communication device determines correctness using one or more common keys stored in its own first storage unit among the authenticators attached to the received message. A determination is preferably made of possible authenticators.

In this aspect, the in-vehicle communication device that receives a message with a plurality of authenticators uses a common key stored therein to determine whether at least one authenticator is correct or incorrect. . As a result, the in-vehicle communication device can detect whether the message is sent by an in-vehicle communication device with a higher security level than its own security level or has an identifier that can determine whether it is correct or not with the common key stored in itself. For example, it is possible to determine whether a message is correct or not and receive it. Therefore, a plurality of vehicle-mounted communication devices connected to a common communication line can simultaneously transmit (broadcast) messages to a plurality of vehicle-mounted communication devices including vehicle-mounted communication devices with different security levels.

(4) One authenticator is attached to the message, and the vehicle-mounted communication device stores one common key determined for its own security level in the first storage unit, and generates the first authenticator. Preferably, the unit uses one common key stored in the first storage unit to generate one authenticator to be attached to other messages to be transmitted.

In this aspect, one authenticator is attached to the message. The in-vehicle communication device stores one common key determined for its own security level, generates one authenticator using this common key, and attaches the generated one authenticator to a message. to send. Thereby, the configuration of each vehicle-mounted communication device can be simplified. In addition, it becomes easy to separate and handle in-vehicle communication devices with different security levels.

(5) When the second authenticator determining unit determines that the authenticator attached to the received message is correct, the in-vehicle communication control device uses a common key different from the common key used to determine the authenticator. A second authenticator generating unit that generates another authenticator using a key, and a different authenticator generated by the second authenticator generating unit and transmitting the received message with the different authenticator generated by the second authenticator generating unit. It is preferable to have a relay section for relaying message transmission/reception between the on-vehicle communication devices of the level.

In this aspect, the in-vehicle communication control device storing each common key receives the message transmitted by the in-vehicle communication device and determines whether the message is correct or not. An identification generated using a common key different from the key is added, and a message with a new identifier is sent to the common communication line. This enables the in-vehicle communication control device to relay message transmission/reception between in-vehicle communication devices having different security levels. Each vehicle-mounted communication device can transmit a message to all vehicle-mounted communication devices connected to a common communication line via the vehicle-mounted communication control device.

(6) The in-vehicle communication device notifies the in-vehicle communication control device when the first authenticator determination unit determines that the authenticator attached to the received message is not correct. wherein the second notification unit of the in-vehicle communication control device determines that the authenticator attached to the received message is not correct, and the second authenticator determination unit of the in-vehicle communication device 1. Notification is preferably performed when a notification is received from the notification unit.

In this aspect, each vehicle-mounted communication device notifies the vehicle-mounted communication control device when it is determined that the authenticator attached to the received message is not correct. When the in-vehicle communication control device determines that the authenticator attached to the message is incorrect and receives a notification from the in-vehicle communication device, it notifies the other in-vehicle communication device. This makes it possible to improve the reliability of notification from the vehicle-mounted communication control device to the vehicle-mounted communication device.

(7) The in-vehicle communication device periodically transmits a keep-alive signal to the common communication line, and the first notification unit notifies the in-vehicle communication control device with the keep-alive signal. preferably.

In this aspect, the in-vehicle communication device notifies the in-vehicle communication control device using a keep-alive signal periodically transmitted by the in-vehicle communication device. As a result, it is possible to prevent the notification from the in-vehicle communication device to the in-vehicle communication control device from interfering with normal message transmission/reception. The in-vehicle communication control device can detect an abnormality related to communication based on the information contained in the keep-alive signal, and can detect the occurrence of some abnormality even when the keep-alive signal is not received.

(8) An in-vehicle communication system according to this aspect includes a plurality of in-vehicle communication devices connected to a common communication line, and an in-vehicle communication device connected to the common communication line and controlling communication of the plurality of in-vehicle communication devices. an in-vehicle communication system comprising a communication control device, wherein an encryption key is determined for each of the in-vehicle communication devices, and the in-vehicle communication device includes a first storage unit that stores the encryption key determined for itself; and a first authenticator generating unit that generates an authenticator to be attached to a message to be transmitted using the encryption key stored in the first storage unit, wherein the in-vehicle communication control device includes each in-vehicle communication device. and a second authenticator determination unit that determines whether the authenticator attached to the received message is correct or not by using the corresponding cryptographic key stored in the second storage unit. have

In this aspect, individual cryptographic keys (which may be common keys or private and public keys) are determined for a plurality of vehicle-mounted communication devices connected to a common communication line. . The in-vehicle communication device stores an encryption key determined for itself, and attaches an authenticator generated using this encryption key to a message and transmits the message. An in-vehicle communication control device stores cryptographic keys determined for each in-vehicle communication device connected to a common communication line, and stores whether an authenticator attached to a received message is correct or not. is determined using the encryption key of As a result, multiple in-vehicle communication devices connected to a common communication line are separated from each other for security reasons, and each in-vehicle communication device individually transmits and receives messages to and from the in-vehicle communication control device. can be enhanced.

(9) The in-vehicle communication device has a first authenticator determination unit that determines whether an authenticator attached to a received message is correct or not using an encryption key stored in the first storage unit, When the second authenticator determination unit determines that the authenticator attached to the received message is correct, the control device uses an encryption key different from the encryption key used to determine the authenticator, and a second authenticator generating unit that generates an authenticator and a second authenticator generating unit that adds another authenticator generated by the second authenticator generating unit to the received message and transmits the message. and a relay unit for relaying message transmission/reception.

In this aspect, each in-vehicle communication device uses its own encryption key to determine whether the authenticator attached to the received message is correct. When the in-vehicle communication control unit determines that the authenticator attached to the received message is correct, it generates an authenticator using an encryption key different from the encryption key used for the determination, and sends the message attached with the generated authenticator. to send. Thereby, the in-vehicle communication control device can relay message transmission/reception between the in-vehicle communication devices. The in-vehicle communication device can transmit and receive messages to and from other in-vehicle communication devices via the in-vehicle communication control device.

(10) The in-vehicle communication control device performs the determination by the second authenticator determination unit before the completion of transmission of the message, and the second authenticator determination unit determines that the authenticator attached to the message is not correct. In this case, it is preferable to have a discard processing unit that performs a process of causing the onboard communication device to discard the message before completing the transmission of the message.

In this aspect, the in-vehicle communication control device determines whether the authenticator attached to the message is correct before the completion of transmission of the message from the in-vehicle communication device. When the in-vehicle communication control device determines that the authenticator is not correct, the in-vehicle communication control device performs a process of discarding the message by a plurality of in-vehicle communication devices connected to the common communication line before completing the transmission of this message. As a result, each in-vehicle communication device does not need to judge whether the authenticator attached to the message is correct or not, and receives the message that was not discarded by the in-vehicle communication control device without judging whether the authenticator is correct or not. can be used for processing.

(11) An in-vehicle communication control device according to this aspect is an in-vehicle communication control device connected to a common communication line to which a plurality of in-vehicle communication devices are connected, and performing control related to communication of the plurality of in-vehicle communication devices, , the plurality of in-vehicle communication devices are classified into a plurality of security levels, a common key is determined for each security level, a storage unit for storing the common key for each security level, and an authentication attached to the received message an authenticator determining unit that determines whether the child is correct or not using the corresponding common key stored in the storage unit; and a notification unit that notifies an in-vehicle communication device that does not store the common key used by the authenticator determination unit in the determination.

In this mode, as in mode (1), it is possible to coexist vehicle-mounted communication devices with different security levels.

(12) When the authenticator determining unit determines that the authenticator attached to the received message is correct, another authenticator is generated using a common key different from the common key used for determining the authenticator. and a relay that relays message transmission/reception between in-vehicle communication devices with different security levels by adding another authenticator generated by the authenticator generating unit to the received message and transmitting the received message. It is preferable to have a part.

In this aspect, as in aspect (5), the in-vehicle communication control device can relay message transmission/reception between in-vehicle communication devices having different security levels.

(13) The in-vehicle communication device notifies when it is determined that the authenticator attached to the received message is not correct, and the notification unit notifies that the authenticator attached to the received message is not correct. It is preferable that the notification is made when the child determination unit makes the determination and the notification is received from the in-vehicle communication device.

In this aspect, similarly to the aspect (6), it is possible to improve the reliability of notification from the vehicle-mounted communication control device to the vehicle-mounted communication device.

(14) The vehicle-mounted communication device according to this aspect is a vehicle-mounted communication device connected to a common communication line, wherein the plurality of vehicle-mounted communication devices connected to the common communication line are classified into a plurality of security levels, A common key is determined for each security level, and a storage unit that stores the common key corresponding to its own security level; an authenticator generation unit that generates an authenticator, an authenticator determination unit that determines whether the authenticator attached to the received message is correct using the common key stored in the storage unit, and an authentication attached to the received message a notification unit that notifies another device connected to the common communication line when the authenticator determination unit determines that the child is not correct.

In this aspect, similarly to the aspect (6), it is possible to improve the reliability of notification from the vehicle-mounted communication control device to the vehicle-mounted communication device.

(15) Preferably, the notification unit notifies by a keep-alive signal periodically transmitted to the common communication line.

In this aspect, similarly to the aspect (7), it is possible to prevent the notification from the in-vehicle communication device to the in-vehicle communication control device from interfering with normal message transmission/reception.

(16) A message can be attached with a plurality of authenticators, and the storage unit stores a common key determined for its own security level and a common key determined for a security level lower than the security level. A common key is stored, and the authenticator generation unit preferably generates one or a plurality of authenticators to be attached to a message to be transmitted using one or a plurality of common keys stored in the storage unit.

In this aspect, as in aspect (2), the in-vehicle communication device can transmit messages to in-vehicle communication devices having the same security level as itself and to in-vehicle communication devices having a lower security level. Become.

(17) The authenticator determination unit performs determination on an authenticator that can determine correctness using one or a plurality of common keys stored in its own storage unit, among the authenticators attached to the received message. is preferred.

In this aspect, as in aspect (3), a plurality of on-vehicle communication devices connected to a common communication line send a message to a plurality of on-board communication devices including on-board communication devices with different security levels. Broadcasting is possible.

(18) A message is attached with one authenticator, the storage unit stores one common key determined for its own security level, and the authenticator generation unit stores the authenticator in the storage unit. Preferably, one common key is used to generate one authenticator attached to other messages to be sent.

In this aspect, similarly to the aspect (4), the configuration of each vehicle-mounted communication device can be simplified, and the vehicle-mounted communication devices with different security levels can be handled separately.

(19) A computer program according to this aspect causes an in-vehicle communication control device connected to a common communication line to which a plurality of in-vehicle communication devices are connected to perform control related to communication of the plurality of in-vehicle communication devices. wherein the plurality of in-vehicle communication devices are classified into a plurality of security levels, a common key is determined for each security level, the common key for each security level is stored in a storage unit, and the in-vehicle communication When the controller determines whether the authenticator attached to the received message is correct or not using the corresponding common key stored in the storage unit, and determines that the authenticator attached to the received message is not correct. Then, a process of notifying an in-vehicle communication device that does not store the common key used in the determination is executed.

In this aspect, similar to aspect (11), vehicle-mounted communication devices with different security levels can coexist.

(20) A computer program according to this aspect is a computer program that causes an in-vehicle communication device connected to a common communication line to perform processing related to communication, and includes a plurality of in-vehicle communication devices connected to the common communication line. A device is classified into a plurality of security levels, a common key is determined for each security level, a common key corresponding to its own security level is stored in a storage unit, and a common key stored in the storage unit is stored. is used to generate an authenticator attached to a message to be transmitted, the correctness of the authenticator attached to the received message is determined using the common key stored in the storage unit, and the authenticator attached to the received message is determined using If it is determined that the received authenticator is not correct, it executes a process of notifying other devices connected to the common communication line.

In this aspect, similarly to the aspect (14), it is possible to improve the reliability of the notification from the vehicle-mounted communication control device to the vehicle-mounted communication device.

(21) In the communication control method according to this aspect, an in-vehicle communication control device connected to a common communication line to which a plurality of in-vehicle communication devices are connected controls communication of the plurality of in-vehicle communication devices. In the method, the plurality of in-vehicle communication devices are classified into a plurality of security levels, a common key is determined for each security level, the common key for each security level is stored in a storage unit, and the received Determining whether the authenticator attached to the message is correct or not using the corresponding common key stored in the storage unit, and if it is determined that the authenticator attached to the received message is not correct, in the determination A notification is sent to the in-vehicle communication device that does not store the used common key.

In this aspect, similar to aspect (11), vehicle-mounted communication devices with different security levels can coexist.

(22) A communication method according to this aspect is a communication method in which an in-vehicle communication device connected to a common communication line performs processing related to communication, wherein the plurality of in-vehicle communication devices connected to the common communication line Classified into a plurality of security levels, a common key is determined for each security level, the common key corresponding to the own security level is stored in a storage unit, and the common key stored in the storage unit is used generates an authenticator attached to a message to be transmitted, determines whether the authenticator attached to the received message is correct using the common key stored in the storage unit, and authenticates the authenticator attached to the received message. If it determines that the child is incorrect, it notifies other devices connected to the common communication line.

In this aspect, similarly to the aspect (14), it is possible to improve the reliability of the notification from the vehicle-mounted communication control device to the vehicle-mounted communication device.

[Details of the embodiment of the present invention]
A specific example of an in-vehicle communication system according to an embodiment of the present invention will be described below with reference to the drawings. The present invention is not limited to these examples, but is indicated by the scope of the claims, and is intended to include all modifications within the scope and meaning equivalent to the scope of the claims.

<Embodiment 1>
1 and 2 are schematic diagrams for explaining an outline of an in-vehicle communication system according to the present embodiment. The in-vehicle communication system according to the present embodiment includes a CGW (Central Gate Way) 2 mounted on a vehicle 1, three DC (Domain Controllers) 3A to 3C, and nine ECUs (Electronic Control Units) 4A to 4I. is configured with CGW 2 is connected to three DCs 3A-3C via separate communication lines. DC3A is connected to three ECUs 4A to 4C via a common communication line (so-called bus). DC3B is connected to three ECUs 4D to 4F via buses. DC3C is connected to each of the three ECUs 4G-4I via individual communication lines.

In the present embodiment, for example, a plurality of ECUs 4A to 4I are classified for each function of the vehicle 1, one DC 3A to 3C is provided for each function, and the corresponding ECUs 4A to 4I are connected via communication lines. DCs 3A to 3C are connected through CGW2. Each of the DCs 3A-3C controls the operation of the ECUs 4A-4I connected thereto, and realizes each function of the vehicle 1. FIG. In addition, DCs 3A to 3C exchange information with each other and cooperate with each other, so that each function cooperates and the functions of the vehicle 1 as a whole are realized.

The CGW 2 and the three DCs 3A to 3C transmit and receive messages by communicating according to the Ethernet (registered trademark) communication protocol, for example. The CGW 2 relays the transmission and reception of messages between the three DCs 3A-3C, for example by transmitting messages received from one DC 3A-3C to the other two DCs 3A-3C. As a result, DCs 3A-3C can send and receive messages to and from other DCs 3A-3C via CGW2. In this embodiment, the CGW 2 is a device that simply relays messages between the three DCs 3A to 3C, but for example, performs arithmetic processing on the received message from one DC 3A to 3C and sends it to the other DCs 3A to 3C. More advanced processing such as sending the calculation result as a message may be performed.

The DC 3A and the three ECUs 4A to 4C transmit and receive messages via the CAN bus by communicating according to the CAN communication protocol, for example. A message transmitted by one ECU 4A-4C can be received by the other ECUs 4A-4C and DC 3A. Messages sent by DC 3A can be received by ECUs 4A-4C.

Similarly, the DC 3B and the three ECUs 4D to 4F transmit and receive messages via the CAN bus by communicating according to the CAN communication protocol, for example. A message transmitted by one ECU 4D-4F can be received by the other ECUs 4D-4F and DC 3B. The message sent by DC3B can be received by ECUs 4D-4F.

The DC 3C and the three ECUs 4G to 4I transmit and receive messages by communicating according to the Ethernet communication protocol, for example. DC3C and ECUs 4G to 4I are connected to each other via individual communication lines, and perform one-to-one message transmission/reception. The DC 3C can relay message transmission/reception among the three ECUs 4G-4I by transmitting messages received from one ECU 4G-4I to the other ECUs 4G-4I. As a result, the ECUs 4G-4I can transmit and receive messages to and from other ECUs 4G-4I via the DC 3B.

It is also possible, for example, to send a message from the ECU 4A connected to DC3A to the ECU 4I connected to DC3C. In this case, the message transmitted from the ECU 4A is relayed by DC3A, CGW2 and DC3 and received by the ECU 4I. By relaying messages by the CGW 2 and the DCs 3A to 3C in this manner, the ECUs 4A to 4I can transmit and receive messages.

In the vehicle-mounted communication system according to the present embodiment, a security level is defined for each device that configures the system. As shown in FIG. 1, in this example, security level 3 is defined for CGW 2 and three DCs 3A-3C, security level 2 is defined for ECUs 4A, 4G-4I, and security level 2 is defined for ECUs 4B-4F. 1 is defined. In FIG. 1, the security level of each device is indicated by the label "LV?". Also, the security level indicates that the higher the numerical value, the higher the security performance.

In the in-vehicle communication system according to the present embodiment, a MAC (Message Authentication Code) is attached to each message transmitted and received by each device. The message includes, for example, an ID indicating the type of message and data such as information to be shared between devices. MAC is information obtained by performing encryption processing using a predetermined encryption key on data included in a message. Each device generates a MAC using its own encryption key and transmits a message attached with the generated MAC. Each device that receives this message determines whether the MAC attached to the message is correct or not using its own encryption key. At this time, each device performs encryption processing using an encryption key on the data contained in the received message to generate a MAC, and the MAC generated by itself matches the MAC attached to the message. Whether the MAC is correct or not can be determined according to whether the MAC is correct or not.

In this embodiment, a common encryption key, ie, a shared key, is stored between devices that transmit and receive messages, and MAC generation and determination are performed. In FIG. 2, encryption keys possessed by each device are illustrated as keys a to e surrounded by dashed lines. For example, the CGW 2 and DCs 3A to 3C of security level 3 use the key e of security level 3 to generate and determine the MAC. The security level 3 DC 3B and the security level 1 ECUs 4D to 4F use the security level 1 key c to generate and determine the MAC. Also, when relaying messages from ECUs 4D to 4F to CGW 2, for example, DC 3B deletes the MAC generated using key c from the received message and adds the MAC generated using key e to the message. Send to CGW2. For example, when relaying a message from CGW 2 to ECUs 4D to 4F, DC 3B deletes the MAC generated using key e from the received message, attaches the MAC generated using key c to the message, and returns it to ECU 4D. Send to ~4F.

Similarly, DC3C of security level 3 and ECUs 4G to 4I of security level 2 use the key d of security level 2 to generate and determine MAC. Also, when relaying messages from ECUs 4G to 4I to CGW 2, for example, DC 3C deletes the MAC generated using key d from the received message and adds the MAC generated using key e to the message. Send to CGW2. Also, when relaying a message from CGW 2 to ECUs 4G to 4I, for example, DC 3C deletes the MAC generated using key e from the received message and attaches the MAC generated using key d to the message. Send to ECU 4G-4I.

As described above, in the in-vehicle communication system according to the present embodiment, for each group of DCs 3A to 3C and ECUs 4A to 4I classified according to, for example, the functions of the vehicle 1, MACs used for communication within the groups are generated and determined. Each encryption key can be different. As a result, it is possible to separate a plurality of devices constituting an in-vehicle communication system into a plurality of groups in terms of security, and set a security level suitable for each group. The security level is determined according to, for example, the strength of the encryption processing algorithm used to generate the MAC, the amount of information (bit length) of the encryption key used for the encryption processing, and the like. The higher the strength of the encryption processing algorithm used and the greater the amount of information in the encryption key, the higher the security level.

In the in-vehicle communication system according to the present embodiment, as shown in DC3A and ECU4A-4C in FIGS. 1 and 2, even if the physical network configuration is one (common), multiple security levels are mixed. It is possible to DC 3A of security level 3, ECU 4A of security level 2, and ECUs 4B and 4C of security level 1 transmit and receive messages using two encryption keys, ie, security level 1 key a and security level 2 key b. Message transmission/reception in a network with mixed security levels will be described below.

FIG. 3 is a schematic diagram showing an example of message transmission/reception by DC 3A and ECUs 4A-4C. As described above, the DC 3A and the ECUs 4A to 4C are connected to a common CAN bus and transmit and receive messages according to the CAN communication protocol. In the illustrated example, level 1 or level 2 is set as the security level of each device (denoted as Lv1 or Lv2 in the figure). In this example, the higher the numerical value of the security level, the higher the level, and the level 2 is higher than the level 1 security level. Security level 2 is set for DC 3A and ECU 4A, and security level 1 is set for ECUs 4B and 4C. In this example, a key a is set as an encryption key for security level 1, and a key b is set as an encryption key for security level 2. FIG. For example, key b is an encryption key with a longer bit length than key a.

In the in-vehicle communication system according to the present embodiment, each device stores an encryption key corresponding to its own security level and an encryption key corresponding to a security level lower than its own security level. For example, the ECUs 4B and 4C with security level 1 store a key a corresponding to their own security level 1. FIG. Also, for example, DC 3A and ECU 4A with security level 2 store key b corresponding to security level 2 of itself and key a corresponding to security level 1 lower than security level 2 of itself.

For example, the ECU 4A of security level 2 storing two keys a and b has MAC (a) generated using the key a and MAC (b ) and transmitted to the CAN bus. Having received this message, the ECUs 4B and 4C of security level 1 use the key a stored therein to determine whether MAC(a) is correct or not, and do not determine (cannot determine) whether MAC(b) is successful or not. The ECUs 4B, 4C determine that the message is valid if the MAC(a) attached to the message is correct. In addition, the DC 3A of security level 2 that receives this message determines whether MAC(b) is correct using the key b stored therein, and determines whether MAC(a) is correct using the key a. DC3A determines that this message is legitimate if MAC(b) and MAC(a) are correct. However, the DC 3A does not have to judge whether MAC(b) with a high security level is correct or not, and MAC(a) with a low security level.

Further, for example, the ECU 4B of security level 1 storing one key a attaches MAC(a) generated using the key a to a message to be transmitted, and transmits the message to the CAN bus. DC 3A and ECUs 4A and 4C that have received this message determine whether MAC(a) is correct or not using key a stored therein. DC 3A and ECUs 4A and 4C determine that this message is legitimate if MAC(a) is correct.

The ECU 4A of security level 2 storing two keys a and b may transmit unnecessary messages to the ECUs 4B and 4C of security level 1 with only MAC(b) attached. Messages to which only MAC(b) is added are discarded because the ECUs 4B and 4C, which do not store the key b, cannot judge whether the messages are correct or not. This message is received at DC3A, which stores key b.

Here, for example, if a malicious device is connected to the CAN bus, or if any device is hijacked, there is a possibility that a message with an incorrect MAC will be sent on the CAN bus. A message with an invalid MAC(a) is detected as invalid by all of the DC 3A and the ECUs 4A to 4C, so that each device can perform processing such as discarding the message. On the other hand, a message with valid MAC(a) and invalid MAC(b) is detected as fraudulent in DC 3A and ECU 4A that store key b. The ECUs 4B and 4C that do not store b cannot detect fraud.

Therefore, in the in-vehicle communication system according to the present embodiment, DC 3A notifies ECUs 4A to 4C when a message with an illegal MAC is received. The DC 3A notifies the ECUs 4A to 4C for which a security level lower than the security level of the MAC determined to be illegal is set. For example, when the MAC (b) of security level 2 is determined to be illegal, DC 3A notifies ECUs 4B and 4C of security level 1 lower than security level 2, and notifies ECU 4A of security level 2. Not performed. However, the configuration may be such that the DC 3A notifies all the ECUs 4A to 4C regardless of the security level. If the MAC(a) of security level 1 is determined to be illegal, the DC 3A does not have a security level lower than this, so it does not need to notify the MAC(a).

FIG. 4 is a schematic diagram showing an example of notification from DC 3A to ECUs 4A-4C. In the in-vehicle communication system according to the present embodiment, in addition to the encryption key used for normal message transmission/reception, each device stores an encryption key used for sending/receiving a notification message when notifying an abnormality such as detection of an unauthorized MAC. are doing. In the illustrated example, the ECU 4A stores the key α, the ECU 4B stores the key β, and the ECU 4C stores the key γ. That is, each device that can receive a notification message stores a different cryptographic key for notification. The DC 3A stores keys α, β, γ of each of the ECUs 4A to 4C to which notification messages can be sent. The key α is a security level 2 encryption key, and the keys β and γ are security level 1 encryption keys. In this embodiment, the keys α, β, and γ are shared keys, but the present invention is not limited to this. , γ may be the public key corresponding to each private key.

When DC 3A detects an abnormality or the like and transmits a notification message to ECUs 4A-4C, DC 3A transmits the notification message individually to ECUs 4A-4C that require notification. When DC 3A transmits a notification message to ECU 4A, DC 3A transmits the notification message with MAC(α) generated using key α of ECU 4A. Since only the ECU 4A having the key α can determine the correctness of the notification message with MAC(α), it is received only by the ECU 4A and discarded by the ECUs 4B and 4C. Similarly, when DC 3A transmits a notification message to ECU 4B, DC 3A transmits the notification message with MAC(β) generated using key β of ECU 4B.

As a result, even if one of the ECUs 4A-4C is hijacked, for example, the keys for sending and receiving notification messages possessed by the other ECUs 4A-4C will not be leaked. can prevent the transmission of the notification message from being blocked.

In the case of this example, the ECU 4A can judge the correctness of both MAC(α) and MAC(b), and does not need a notification message from the DC 3A due to the detection of an unauthorized MAC. There is no need to store the key α for sending and receiving messages. However, when DC 3A performs notification other than detection of an unauthorized MAC, DC 3A may transmit a notification message with MAC (α) using key α, and ECU 4A does not store key α. It is preferable to keep

Further, the DC 3A may be configured to attach a plurality of MACs to the notification message and transmit the notification message. For example, when transmitting a notification message to ECUs 4B and 4C, DC 3A may transmit a notification message with MAC(β) and MAC(γ). When the ECUs 4B and 4C that have received this notification message use the keys β and γ stored therein to determine that any MAC is valid, the ECU 4B or 4C treats this notification message as a valid message.

FIG. 5 is a block diagram showing the configuration of DC3A according to this embodiment. The other DCs 3B and 3C have the same configuration as the DC 3A, so illustration and description are omitted. The DC 3A according to this embodiment includes a processing unit (processor) 31, a storage unit (storage) 32, a CAN communication unit (transceiver) 33, an Ethernet communication unit (transceiver) 34, and the like. The processing unit 31 is configured using an arithmetic processing device such as a CPU (Central Processing Unit) or an MPU (Micro-Processing Unit). The processing unit 31 reads out and executes a program 32a stored in the storage unit 32 to transmit/receive messages with the CGW 2 and the ECUs 4A to 4C, detect unauthorized messages based on MAC, and send messages to the ECUs 4A to 4C. Notification, etc.

The storage unit 32 is configured using a non-volatile memory device such as a flash memory or EEPROM (Electrically Erasable Programmable Read Only Memory). The storage unit 32 stores various programs executed by the processing unit 31 and various data required for processing by the processing unit 31 . In the present embodiment, the storage unit 32 stores a program 32a executed by the processing unit 31, and is provided with a key storage unit 32b that stores an encryption key used for MAC generation and determination. The program 32a may be written in the storage unit 32 at the manufacturing stage of the DC 3A, for example, or may be distributed by a remote server device or the like, and may be acquired by the DC 3A through communication. The program 32a recorded in the recording medium 99 such as the DC 3A may be read out and stored in the storage unit 32. Alternatively, the program 32a recorded in the recording medium 99 may be read out by the writing device and written in the storage unit 32 of the DC 3A. It's okay. The program 32 a may be provided in the form of distribution via a network, or may be provided in the form of being recorded on the recording medium 99 .

The key storage unit 32b of the storage unit 32 stores keys a and b for generating and determining MACs attached to messages transmitted/received between the ECUs 4A to 4C, and keys a and b attached to messages transmitted/received between the CGW 2. A key e for generating and determining the MAC to be used is stored. The key storage unit 32b also stores keys α, β, γ for generating and determining MACs attached to notification messages transmitted and received between the ECUs 4A to 4C when an abnormality is detected. The encryption keys stored in the key storage unit 32b are different among the DCs 3A to 3C.

The DC 3A also stores, for example, as a table information about the plurality of encryption keys stored in the key storage unit 32b. FIG. 6 is a schematic diagram showing an example of information about encryption keys stored in a table. The illustrated table stores a device to which DC 3A sends and receives messages, the security level of this device, an ID (eg, CAN-ID) attached to a message sent by this device, and this device. Correspondence between encryption keys and notification message encryption keys stored in this device is stored. For example, when DC 3A receives a message from ECUs 4A to 4C, for example, it determines the source device of the message based on the ID attached to the message, reads out the corresponding encryption key from key storage unit 32b, and stores the MAC. can judge.

The CAN communication unit 33 performs wired communication according to the CAN communication protocol. The CAN communication unit 33 can be configured using a so-called CAN transceiver IC. The CAN communication unit 33 is connected to a plurality of ECUs 4A to 4C via a CAN bus arranged in the vehicle 1, and performs communication with these ECUs 4A to 4C according to the CAN communication protocol. The CAN communication unit 33 converts the transmission message given from the processing unit 31 into an electric signal according to the CAN communication protocol and outputs the electric signal to the communication line, thereby transmitting the message to the ECUs 4A to 4C. Also, the CAN communication unit 33 receives messages from the ECUs 4A to 4C by sampling and obtaining the potential of the communication line, and gives the received messages to the processing unit 31 .

The Ethernet communication unit 34 performs wired communication according to the Ethernet communication protocol. The Ethernet communication unit 34 is connected to the CGW 2 via an Ethernet communication line arranged in the vehicle 1 and performs communication with the CGW 2 according to the Ethernet communication protocol. The Ethernet communication unit 34 converts the transmission message given from the processing unit 31 into an electric signal according to the Ethernet communication protocol and outputs the electric signal to the communication line, thereby transmitting the message to the CGW 2 . Also, the Ethernet communication unit 34 receives a message from the CGW 2 by sampling and acquiring the potential of the communication line, and gives the received message to the processing unit 31 . In addition, in the system configuration illustrated in FIGS. 1 and 2 , the DC 3C does not include the CAN communication unit 33 but includes a plurality of Ethernet communication units 34 .

Further, in the DC 3A according to the present embodiment, the processing unit 31 reads out and executes the program 32a stored in the storage unit 32, so that the MAC generation unit 31a, the MAC determination unit 31b, the transmission/reception processing unit 31c, and the notification processing unit 31d etc. are implemented in the processing unit 31 as software functional blocks. The MAC generation unit 31a encrypts a message to be transmitted to the CGW 2 or ECUs 4A to 4C using the encryption key stored in the key storage unit 32b, thereby generating a MAC for authenticating the message. Do the process to generate. The MAC generation unit 31a generates a MAC using the key e stored in the key storage unit 32b for a message to be transmitted to the CGW 2. FIG. The MAC generator 31a also generates a MAC using the key a stored in the key storage unit 32b and a MAC using the key b for messages to be transmitted to the ECUs 4A to 4C.

The MAC determination unit 31b performs processing for determining whether the MAC attached to the message received from the CGW 2 or the ECUs 4A to 4C is correct. The MAC determination unit 31b refers to the table shown in FIG. 5 based on the ID included in the received message, and determines the encryption key used for determination. The MAC determination unit 31b generates a MAC for the received message using an encryption key, and determines whether the MAC is correct or not depending on whether the generated MAC matches the MAC attached to the received message. judge. The MAC determination unit 31b performs MAC determination using the key e stored in the key storage unit 32b for the message received from the CGW 2 . The MAC determination unit 31b performs MAC determination using the keys a and b stored in the key storage unit 32b for the message received from the ECU 4A. The MAC determination unit 31b performs MAC determination using the key a stored in the key storage unit 32b for messages received from the ECUs 4B and 4C.

The transmission/reception processing unit 31c performs processing for transmitting/receiving messages to/from the CGW 2 or the ECUs 4A to 4C. The transmission/reception processing unit 31c attaches the MAC generated by the MAC generation unit 31a to the message to be transmitted, and provides the MAC-attached message to the CAN communication unit 33 or the Ethernet communication unit 34, so that the ECUs 4A to 4C or CGW 2 Send a message to Further, the transmission/reception processing unit 31c causes the MAC determination unit 31b to determine whether or not the MAC attached to the message received by the CAN communication unit 33 or the Ethernet communication unit 34 is successful or not, and the message to which the regular MAC is attached is sent. Treat as a received message and discard a message with an invalid MAC attached.

The notification processing unit 31d performs processing for transmitting a notification message to the ECUs 4A to 4C when the MAC determination unit 31b determines that the MAC is invalid. The notification processing unit 31d checks the security level of the MAC determined to be unauthorized by the MAC determination unit 31b, and the ECUs 4A to 4C that do not have the encryption key corresponding to this security level. A notification message is sent to the ECUs 4A to 4C for which a low security level has been set. The notification message may include information such as the security level of the MAC determined to be unauthorized, the ID included in the message attached with this MAC, and the identification information of the ECUs 4A to 4C that sent this message. The ECUs 4A to 4C that have received the notification message can store the information contained in the notification message, and can perform processing such as discarding the same message when receiving a similar message thereafter.

FIG. 7 is a block diagram showing the configuration of the ECU 4A according to this embodiment. Since the other ECUs 4B to 4I have the same configuration as the ECU 4A, illustration and description thereof will be omitted. The ECU 4A according to the present embodiment includes a processing section (processor) 41, a storage section (storage) 42, a CAN communication section (transceiver) 43, and the like. The processing unit 41 is configured using an arithmetic processing unit such as a CPU or MPU. The processing unit 41 reads out and executes a program 42a stored in the storage unit 42 to perform transmission/reception of messages with the DC 3A and other ECUs 4B and 4C, detection of unauthorized messages based on MAC, and the like.

The storage unit 42 is configured using a non-volatile memory device such as flash memory or EEPROM. The storage unit 42 stores various programs executed by the processing unit 41 and various data required for processing by the processing unit 41 . In the present embodiment, the storage unit 42 stores a program 42a executed by the processing unit 41, and is provided with a key storage unit 42b that stores an encryption key used for MAC generation and determination. The program 42a may be written in the storage unit 42 at the manufacturing stage of the ECU 4A, for example, or may be distributed by a remote server device or the like, and may be acquired by the ECU 4A through communication. The program 42a recorded in the recording medium 98 such as the ECU 4A may be read out and stored in the storage unit 42. Alternatively, the program 42a recorded in the recording medium 98 may be read out by a writing device and written in the storage unit 42 of the ECU 4A. It's okay. The program 42 a may be provided in the form of distribution via a network, or may be provided in the form of being recorded on the recording medium 98 .

A key storage unit 42b of the storage unit 42 stores keys a and b for generating and determining MACs attached to messages transmitted/received between the DC 3A and other ECUs 4B and 4C. Further, the key storage unit 42b stores a key α for generating and determining a MAC attached to a notification message to be transmitted/received with the DC 3A when an abnormality is detected. The encryption keys stored in the key storage unit 42b are different among the ECUs 4A to 4I.

The CAN communication unit 43 performs wired communication according to the CAN communication protocol. The CAN communication unit 43 can be configured using a so-called CAN transceiver IC. The CAN communication unit 43 is connected to the DC 3A and other ECUs 4B and 4C via a CAN bus arranged in the vehicle 1, and performs communication with the DC 3A and the ECUs 4B and 4C according to the CAN communication protocol. The CAN communication unit 43 converts the transmission message given from the processing unit 41 into an electric signal according to the CAN communication protocol and outputs the electric signal to the communication line, thereby transmitting the message to the DC 3A and the ECUs 4B and 4C. . The CAN communication unit 43 also receives messages from the DC 3A and the ECUs 4B and 4C by sampling and acquiring the potential of the communication line, and gives the received messages to the processing unit 41 . In the system configuration illustrated in FIGS. 1 and 2, the ECUs 4G to 4I do not have the CAN communication unit 43, but instead have an Ethernet communication unit that performs communication according to the Ethernet communication protocol.

In the ECU 4A according to the present embodiment, the program 42a stored in the storage unit 42 is read out and executed by the processing unit 41, whereby the MAC generation unit 41a, the MAC determination unit 41b, the transmission/reception processing unit 41c, and the notification processing unit 41d etc. are implemented as software functional blocks in the processing unit 41 . The MAC generating unit 41a encrypts a message to be transmitted to the DC 3A and the ECUs 4B and 4C using the encryption key stored in the key storage unit 42b, thereby generating a MAC for authenticating the message. Do the process to generate. The MAC generation unit 41a generates a MAC using the key a stored in the key storage unit 32b and a MAC using the key b.

The MAC determination unit 41b performs processing for determining whether the MAC attached to the message received from the DC 3A or the ECUs 4B and 4C is correct. The MAC determination unit 41b generates a MAC using an encryption key for the received message, and determines whether the MAC is correct or not depending on whether the generated MAC matches the MAC attached to the received message. judge. When two MACs are attached to the received message, the MAC determination unit 41b performs correctness determination using the two keys a and b for the corresponding MACs. Further, when one MAC is attached to the received message, the MAC determination unit 41b performs right/wrong determination using one key a.

The transmission/reception processing unit 41c performs processing for transmitting and receiving messages between the DC 3A and the ECUs 4B and 4C. The transmission/reception processing unit 41c attaches the MAC generated by the MAC generation unit 41a to the message to be transmitted, and provides the message with the MAC to the CAN communication unit 43, thereby transmitting the message to the DC 3A and the ECUs 4B and 4C. . In addition, the transmission/reception processing unit 41c causes the MAC determination unit 41b to determine success or failure of the MAC attached to the message received by the CAN communication unit 43, and treats the message to which the regular MAC is attached as the received message. , discard messages with invalid MACs.

The notification processing unit 41d performs processing for notifying the DC 3A and the ECUs 4B and 4C that it is operating normally by transmitting a signal to the CAN bus at a predetermined cycle. The periodic signal transmission by the notification processing unit 41d is a so-called keep-alive function, and hereinafter, the periodically transmitted signal is referred to as a keep-alive signal. In the present embodiment, when the MAC determination unit 41b determines that the MAC is invalid, the notification processing unit 41d includes information about the invalidation determination in the keep-alive signal and transmits the invalid MAC to the DC 3A. is detected. At this time, the notification processing unit 41d includes information such as the number of times an invalid MAC is detected, the security level of the MAC determined as invalid, or the ID of the message attached with the MAC determined as invalid in the keep-alive signal. be able to.

In the in-vehicle communication system according to the present embodiment, the DC 3A transmits a notification message in response to detection of an unauthorized MAC as described above. The following three variations can be adopted for the transmission timing of this notification message of DC3A. DC3A may employ any of the three transmission timings for the notification message.
(1) Immediate notification (2) Single agreement notification (3) Multiple agreement notification

FIG. 8 is a schematic diagram for explaining the transmission timing of the notification message of DC3A. This figure is a timing chart in which the horizontal axis is time t, and the timing at which DC 3A detects an unauthorized MAC is time t0. Further, the timing at which the DC 3A receives a keep-alive signal from the first ECU notifying that an unauthorized MAC has been detected is time t1, and the timing at which the same keep-alive signal is received from the second ECU is time t2, The timing at which a similar keep-alive signal is received from the third ECU is defined as time t3. Note that this example assumes a network configuration in which more ECUs are connected to the DC 3A via a CAN bus than the network configuration shown in FIGS. 3 and 4 and the like.

(1) Immediate notification DC 3A promptly transmits a notification message after determining that the MAC attached to the message received by DC 3A is invalid by MAC determination unit 31b. In this case, the DC 3A transmits the notification message based only on the determination of its own MAC determination section 31b. This is the method by which the notification message can be sent at the earliest timing.

(2) Single Agreement Notification DC3A waits for reception of a keep-alive signal periodically transmitted by another ECU after the MAC determination unit 31b determines that the MAC attached to the message received by DC3A is invalid. . When DC 3A receives a keep-alive signal including information indicating that an unauthorized MAC has been detected from any ECU, DC 3A transmits a notification message to the required ECU. The ECU associates the keep-alive signal with, for example, the security level of the detected unauthorized MAC or the ID of the message attached with this MAC, and the number of times the unauthorized MAC was detected after the previous keep-alive signal was transmitted. including the information of When the DC 3A receives a keep-alive signal containing information indicating that an unauthorized MAC has been detected for the same security level as the security level at which the DC 3A has detected an unauthorized MAC from any one ECU, the security level is higher than this security level. Send a notification message to the ECU with a lower security level. After receiving the keep-alive signal from the ECU, DC3A immediately transmits the notification message. DC 3A waits not only for its own judgment, but also for at least one other ECU's judgment before transmitting the notification message, and the reliability of the notification message can be improved.

(3) Multiple agreement notification DC3A includes information to the effect that an unauthorized MAC has been detected from a predetermined number (for example, a majority) of ECUs for which a security level equal to or higher than the security level of the MAC determined to be unauthorized has been set. When the keep-alive signal is received, a notification message is sent to the ECU set to a security level lower than this security level. In the illustrated example, DC3A immediately sends a notification message after receiving keep-alive signals from the three ECUs. By having DC 3A wait for keep-alive signals from a plurality of ECUs before transmitting the notification message, the reliability of the notification message can be further improved.

FIG. 9 is a flowchart showing the procedure of message reception processing performed by the ECU 4A according to the present embodiment. Similar processing is performed for the other ECUs 4B to 4I. The transmission/reception processing unit 41c of the processing unit 41 of the ECU 4A according to the present embodiment determines whether or not the CAN communication unit 43 has received a message from the other ECUs 4B, 4C or DC 3A (step S1). If no message has been received (S1: NO), the transmission/reception processor 41c waits until a message is received. When a message is received (S1: YES), the transmission/reception processing unit 41c acquires the MAC attached to the received message (step S2).

The MAC determination unit 41b of the processing unit 41 determines whether or not the MAC acquired in step S2 is correct (step S3). At this time, the MAC determination unit 41b determines whether the MAC generated from the received message using the encryption key stored in the key storage unit 42b matches the MAC obtained in step S2. Judge right or wrong. If the MAC is correct (S3: YES), the transmission/reception processing unit 41c terminates the message reception process.

If the MAC is not correct (S3: NO), the transmission/reception processor 41c discards the received message (step S4). The ECU 4A also stores the number of MAC errors for each security level in the storage unit 42, for example. The transmission/reception processing unit 41c stores the number of errors corresponding to the MAC security level determined to be invalid in step S3 (step S5), and ends the message reception processing.

FIG. 10 is a flowchart showing the procedure of the keep-alive signal transmission process performed by the ECU 4A according to the present embodiment. The notification processing unit 41d of the processing unit 41 of the ECU 4A according to the present embodiment determines whether or not it is time to transmit a keep-alive (KA) signal that is periodically transmitted (step S11). If the keep-alive signal transmission timing has not come yet (S11: NO), the notification processing unit 41d waits until the keep-alive signal transmission timing comes. When the transmission timing of the keep-alive signal has come (S11: YES), the notification processing unit 41d refers to the number of errors for each security level stored in the storage unit 42 to determine whether or not there is an error related to the MAC (step S12).

If no error has occurred (S12: NO), that is, if no unauthorized MAC has been detected since the transmission of the previous keep-alive signal, the notification processing unit 41d performs a normal keep-alive message that does not include information about an unauthorized MAC. I need to send an alive signal. Therefore, the MAC generation unit 41a of the processing unit 41 generates and adds a MAC for the normal keep-alive signal (step S15). The notification processing unit 41d transmits the MAC-added keep-alive signal through the CAN communication unit 43 (step S16), and ends the process.

If an error has occurred (S12: YES), the notification processing unit 41d keeps alive information related to detection of an unauthorized MAC, such as the number of errors for each security level stored in the storage unit 42. It is added to the signal (step S13). The notification processing unit 41d also initializes the number of errors for each security level stored in the storage unit 42 (step S14). After that, the MAC generation unit 41a generates and adds a MAC to the keep-alive signal to which information about the illegal MAC is added (step S15). The notification processing unit 41d transmits the MAC-added keep-alive signal through the CAN communication unit 43 (step S16), and ends the process.

FIG. 11 is a flow chart showing the procedure of notification message transmission processing performed by the DC 3A according to the present embodiment, which is the procedure for the above (1) immediate notification. The transmission/reception processing unit 31c of the processing unit 31 of the DC 3A according to the present embodiment determines whether or not the CAN communication unit 33 has received a message from the ECUs 4A to 4C (step S21). If no message has been received (S21: NO), the transmission/reception processor 31c waits until a message is received. If a message has been received (S21: YES), the transmission/reception processing unit 31c acquires the MAC attached to the received message (step S22).

The MAC determination unit 31b of the processing unit 31 determines whether or not the MAC acquired in step S22 is correct (step S23). At this time, the MAC determination unit 31b refers to the table shown in FIG. 6 to determine the encryption key to be used to determine whether the MAC attached to the received message is correct. The MAC determination unit 31b determines whether the MAC is correct or not based on whether the MAC generated from the received message using the encryption key stored in the key storage unit 32b matches the MAC obtained in step S22. do. If the MAC is correct (S23: YES), the transmission/reception processing unit 41c terminates the process without transmitting the notification message.

If the MAC is not correct (S23: NO), the transmission/reception processor 41c discards the received message (step S24). Next, the notification processing unit 31d of the processing unit 31 generates a notification message to notify that an unauthorized MAC has been detected (step S25). The notification message includes, for example, information such as the security level of the MAC determined to be unauthorized or the ID of the message attached with this MAC. The MAC generation unit 31a of the processing unit 31 generates and adds a MAC to the notification message generated in step S25 (step S26). At this time, the MAC generation unit 31a reads the notification key information stored for the ECUs 4A to 4C to which the notification message is to be transmitted from the key storage unit 32b, and generates different MACs for each of the ECUs 4A to 4C. Therefore, when transmitting notification messages to a plurality of ECUs 4A to 4C, a plurality of notification messages with different MACs are generated. The notification processing unit 31d transmits the MAC-attached notification message through the CAN communication unit 33 (step S27), and ends the process.

FIG. 12 is a flow chart showing the procedure of notification message transmission processing performed by the DC 3A according to the present embodiment, which is the procedure in the case of the above (2) single agreement notification. The transmission/reception processing unit 31c of the processing unit 31 of the DC 3A according to the present embodiment determines whether or not the CAN communication unit 33 has received a message from the ECUs 4A to 4C (step S31). If no message has been received (S31: NO), the transmission/reception processor 31c waits until a message is received. If a message has been received (S31: YES), the transmission/reception processing unit 31c acquires the MAC attached to the received message (step S32). The MAC determination unit 31b of the processing unit 31 determines whether or not the MAC acquired in step S32 is correct (step S33). If the MAC is correct (S33: YES), the transmission/reception processing unit 41c terminates the process without transmitting the notification message. If the MAC is not correct (S33: NO), the transmission/reception processor 31c discards the received message (step S34).

Thereafter, the notification processing unit 31d determines whether or not the CAN communication unit 33 has received the keep-alive signal transmitted from the ECUs 4A to 4C (step 35). When the keep-alive signal is received (S35: YES), the notification processing unit 31d confirms that the MAC attached to the received keep-alive signal is correct, and then adds an invalid MAC to the received keep-alive signal. It is determined whether information related to detection has been added (step S36). If the keep-alive signal is accompanied by unauthorized MAC information (S36: YES), the notification processing unit 31d uses the unauthorized MAC determination result indicated in the information appended to the keep-alive signal and the It is determined whether or not the determination result of its own unauthorized MAC matches (step S37).

If the keep-alive signal is not received from the ECUs 4A to 4C (S35: NO), if the received keep-alive signal is not accompanied by illegal MAC information (S36: NO), or is attached to the keep-alive signal If the determination result indicated by the information does not match its own determination result (S37: NO), the notification processing unit 31d returns the process to step S35, Wait until an alive signal is received.

If the determination result indicated by the information attached to the keep-alive signal matches its own determination result (S37: YES), the notification processing unit 31d generates a notification message to notify that an unauthorized MAC has been detected, A MAC using the key information for notification is attached to this notification message, and the notification message with the MAC attached is transmitted by the CAN communication unit 33 (step S38), and the process ends.

In the above (3) procedure of notification message transmission processing in the case of multiple agreement notification, the processing related to the keep-alive signal shown in steps S35 to S37 may be repeated for a plurality of ECUs 4A to 4C. Illustration of the flowchart in this case and detailed description of the procedure are omitted.

In the in-vehicle communication system according to the present embodiment having the above configuration, DC 3A and a plurality of ECUs 4A to 4C are connected to a common CAN bus. A plurality of ECUs 4A to 4C are classified into a plurality of security levels (levels 1 and 2), and common keys (keys a and b) are determined for each security level. Each of the ECUs 4A to 4C stores one or more keys a and b according to its own security level in the key storage unit 42b, and attaches a MAC generated using the stored keys a and b to the message. While transmitting, it determines whether the MAC attached to the received message is correct. Since messages with MACs generated using different keys a and b are transmitted and received on a common CAN bus, each ECU 4A to 4C generates keys a and b that are the same as the keys a and b that it owns. However, it cannot judge the success or failure of messages with MACs generated with keys a and b that it does not own.

The DC 3A stores the keys a and b of each security level in the key storage unit 32b, and makes determination using the keys a and b corresponding to the MAC attached to the received message. DC3A can determine the correctness of the MAC attached to all the messages transmitted and received via the common CAN bus. When DC 3A receives a message with an incorrect MAC attached, it sends a notification message to ECUs 4A to 4C that do not have the keys a and b used to determine this MAC.

As a result, each ECU 4A-4C judges by itself the messages that can judge whether the MAC is correct or not by the keys a and b stored in itself, and receives the notification message from the DC 3A for the messages that cannot be judged by itself. , it can be determined that an unauthorized message has been sent to the common CAN bus. Therefore, ECUs 4A to 4C with different security levels can coexist on a common CAN bus.

Moreover, in the in-vehicle communication system according to the present embodiment, it is possible to attach a plurality of MACs to a message. Each of the ECUs 4A-4C stores keys a and b determined for its own security level and keys a and b determined for a security level lower than its own security level. The ECUs 4A to 4C, which store a plurality of keys a and b, generate a plurality of MACs using the plurality of keys a and b, attach the generated MACs to a message, and transmit the message. This allows the ECUs 4A-4C to transmit messages to the ECUs 4A-4C having the same security level as themselves and to the ECUs 4A-4C having a lower security level.

In addition, in the in-vehicle communication system according to the present embodiment, each of the ECUs 4A to 4C that has received a message with a plurality of MACs uses the keys a and b stored therein to determine whether it is correct or not. Make a right/wrong judgment. As a result, the ECUs 4A to 4C, even if the messages are transmitted by the ECUs 4A to 4C with security levels higher than their own security levels, are messages with MACs attached that can determine whether they are correct or not using the keys a and b stored in themselves. If so, it is possible to judge whether the message is correct or not and receive it. Therefore, a plurality of ECUs 4A-4C connected to a common CAN bus can simultaneously transmit messages to a plurality of ECUs 4A-4C including ECUs 4A-4C with different security levels.

Further, in the in-vehicle communication system according to the present embodiment, when it is determined that the MAC attached to the received message is incorrect, each of the ECUs 4A to 4C notifies the DC 3A using the keep-alive signal. When DC 3A determines by itself that the MAC attached to the message is incorrect and receives a notification from ECUs 4A-4C, DC 3A transmits a notification message to the effect that an incorrect MAC has been detected to ECUs 4A-4C. do. This makes it possible to improve the reliability of notification messages from DC 3A to ECUs 4A-4C. Also, by notifying DC 3A from ECUs 4A-4C using keep-alive signals, it is possible to prevent the notification from ECUs 4A-4C to DC 3A from interfering with normal message transmission/reception. The DC 3A can detect a communication-related abnormality based on the information contained in the keep-alive signal, and can detect the occurrence of some abnormality even when the keep-alive signal is not received.

In the present embodiment, each ECU 4A-4C is configured to store individual keys α, β, γ in order to generate and determine MAC attached to notification messages from DC 3A to ECUs 4A-4C. is not limited to A configuration in which the DC 3A and the ECUs 4A to 4C do not have a special encryption key for transmitting and receiving notification messages may also be used. Also, the notification message may be sent all at once to all the ECUs 4A-4C instead of being sent individually to each of the ECUs 4A-4C.

Also, the illustrated device configuration, network configuration, system configuration, and the like of the in-vehicle communication system are examples, and are not limited to these. Also, the security level classification, common key allocation, and the like shown in the table of FIG. 6 are merely examples, and are not limited to these.

<Embodiment 2>
FIG. 13 is a schematic diagram showing an example of message transmission/reception by DC 3A and ECUs 4A to 4C according to the second embodiment. In the in-vehicle communication system according to the second embodiment, each of the ECUs 4A to 4C stores only one key a, b corresponding to its own security level, and does not store keys a, b with security levels lower than its own security level. . Each of the ECUs 4A to 4C generates a MAC using one key a, b stored therein, and transmits a message with one MAC attached. In the illustrated example, the ECU 4A storing the key b corresponding to security level 2 generates MAC(b) using the key b, attaches MAC(b) to the message, and transmits the message. This message is not received by ECUs 4B and 4C that do not store key b. DC 3A stores keys a and b of all security levels, and can determine whether the received message is correct or not using key b corresponding to MAC(b) attached to the received message.

In the in-vehicle communication system according to the second embodiment, the ECUs 4A-4C cannot directly transmit/receive messages with other ECUs 4A-4C that do not have the same keys a and b as themselves. Therefore, the DC 3A according to the second embodiment performs processing for relaying messages between different security levels. In the illustrated example, DC 3A, which receives a message with MAC(b) from ECU 4A, determines that the message is valid using key b stored therein, and then stores it. MAC(a) is generated and added to this message using the key a stored therein, and the message with MAC(a) is transmitted to the ECUs 4B and 4C. The ECUs 4B and 4C use the key a stored therein to determine whether the MAC(a) attached to the message from the DC 3A is correct or not, and receive this message.

DC3A transmits a notification message when it determines that the MAC attached to the received message is invalid. In the first embodiment, the DC 3A transmits the notification message to the ECUs 4A to 4C with security levels lower than the security level of the unauthorized MAC. On the other hand, the DC 3A according to the second embodiment transmits a notification message to the ECUs 4A to 4C with security levels different from the security level of the unauthorized MAC. In the illustrated example, for example, when it is determined that the MAC (a) attached to the message transmitted by the ECU 4B is invalid, the DC 3A sets the security level 2 different from the security level 1 of the MAC (a), that is, the MAC A notification message is sent to the ECU 4A that does not have the key a necessary for the determination of (a).

FIG. 14 is a flow chart showing a procedure of processing performed by the DC 3A according to the second embodiment. The transmission/reception processing unit 31c of the processing unit 31 of the DC 3A according to the second embodiment determines whether or not the CAN communication unit 33 has received a message from the ECUs 4A to 4C (step S41). If no message has been received (S41: NO), the transmission/reception processor 31c waits until a message is received. If a message has been received (S41: YES), the transmission/reception processing unit 31c acquires the MAC attached to the received message (step S42).

The MAC determination unit 31b of the processing unit 31 determines whether or not the MAC acquired in step S42 is correct (step S43). If the MAC is not correct (S43: NO), the transmission/reception processor 41c discards the received message (step 44). Next, the notification processing unit 31d of the processing unit 31 generates a notification message for notifying that an unauthorized MAC has been detected (step S45). The MAC generation unit 31a of the processing unit 31 generates and adds a large MAC to the notification message generated in step S45 (step S46). The notification processing unit 31d transmits the MAC-attached notification message through the CAN communication unit 33 (step S47), and ends the process.

If the MAC is correct (S43: YES), the transmission/reception processing unit 41c reads out from the key storage unit 32b an encryption key with a security level different from the MAC determined to be correct, and uses the MAC with a different security level for the received message. is generated (step S48). The transmission/reception processing unit 41c deletes the MAC attached to the received message and attaches the MAC generated in step S48 to the message, thereby exchanging the MAC of the message (step S49). The transmission/reception processing unit 41c relays the message between the different security levels by transmitting the MAC-exchanged message through the CAN communication unit 33 (step S50), and ends the process.

In the in-vehicle communication system according to Embodiment 2 having the above configuration, one MAC is attached to each message. Each of the ECUs 4A to 4C stores one key a, b determined for its own security level, generates one MAC using the keys a, b, and converts the generated MAC into a message. attached and sent. This makes it possible to simplify the configuration of each of the ECUs 4A-4C. In addition, it becomes easy to handle the ECUs 4A to 4C with different security levels separately.

Further, the DC 3A according to the second embodiment receives messages transmitted by the ECUs 4A to 4C and determines whether the MAC is correct or not. , and transmits the message with the new MAC to the CAN bus. This enables DC 3A to relay message transmission/reception between ECUs 4A to 4C having different security levels. Each ECU 4A-4C can transmit messages to all ECUs 4A-4C connected to the CAN bus via DC 3A.

Other configurations of the on-vehicle communication system according to Embodiment 2 are the same as those of the on-vehicle communication system according to Embodiment 1, so the same parts are given the same reference numerals, and detailed descriptions thereof are omitted.

<Embodiment 3>
FIG. 15 is a schematic diagram showing an example of message transmission/reception by DC 303A and ECUs 304A to 304C according to the third embodiment. In the in-vehicle communication system according to Embodiment 3, a plurality of ECUs 304A to 304C connected to a common CAN bus each store one different key x to z. DC 303A connected to this CAN bus stores keys x to z of ECUs 304A to 304C. Each ECU 304A-304C generates a MAC using one key xz stored therein, and transmits a message with one MAC attached. In the illustrated example, ECU 304A that stores key x generates MAC(x) using key x, attaches MAC(x) to a message, and transmits the message.

In the in-vehicle communication system according to Embodiment 3, each of the ECUs 304A-304C does not determine whether the MAC attached to the received message is correct. Therefore, even the ECUs 304B and 304C, which do not store the key x, can receive the message with MAC(x) sent by the ECU 403A. The ECUs 304B and 304C use this message for their own processing without judging whether the MAC(x) attached to the received message is correct.

In the in-vehicle communication system according to the third embodiment, DC 303A determines whether MACs attached to messages transmitted by ECUs 403A to 403C are correct. Messages transmitted and received by the in-vehicle communication system according to the third embodiment may employ a data frame configuration of the CAN communication protocol. A CAN data frame is composed of a plurality of fields such as a start of frame, an arbitration field, a control field, a data field, a CRC field, an ACK field and an end of frame. The MAC is stored in part of the data field, for example.

FIG. 16 is a schematic diagram for explaining message discarding by DC 303A according to the third embodiment. DC 303A according to Embodiment 3 monitors message transmission to the CAN bus by one of ECUs 304A to 304C. After the transmission of the message is started, DC 303A determines whether the MAC included in the data field is correct or not when the transmission of the data field is completed. DC303A obstructs transmission of this message by transmitting the error frame prescribed|regulated to the communication protocol of CAN, before transmission of this message is completed, when it determines with MAC being unjust. As a result, the transmission of the message with the invalid MAC is interrupted, and the message is discarded by the ECUs 304A-304C.

Processing such as MAC determination and error frame transmission performed by DC 303A according to the third embodiment must be performed before message transmission is completed by ECUs 304A to 304C. Therefore, it is preferable that these processes are performed by the CAN communication unit 33 instead of by the processing unit 31 of the DC 303A.

Further, the method by which DC 303A causes ECUs 304A to 304C to discard messages is not limited to transmission of error frames. For example, the DC 303A may output to the CAN bus a signal that inverts data of a predetermined bit included in the message, thereby causing the ECUs 304A to 304C to discard the data. DC 303A can cause ECUs 304A to 304C to discard the message by changing the message so that ECUs 304A to 304C cannot judge it as a valid message before the transmission of the message is completed.

FIG. 17 is a flowchart showing a procedure of processing performed by DC 303A according to the third embodiment. The DC 303A according to the third embodiment determines whether or not any of the ECUs 304A to 304C connected to the CAN bus has transmitted a message (step S61). If the message has not been transmitted (S61: NO), DC 303A waits until the message is transmitted. If the message has been transmitted (S61: YES), the DC 303A determines whether transmission of the MAC included in this message has ended (step S62). If MAC transmission has not ended (S62: NO), DC 303A waits until MAC transmission ends.

When the transmission of the MAC has ended (S62: YES), the DC 303A determines whether or not the MAC is correct for the message being transmitted (step S63). If it is determined that the MAC is incorrect (S63: NO), the DC 303A transmits an error frame to the CAN bus before completing the transmission of this message (step S64), and terminates the process. If the MAC is determined to be correct (S63: YES), the DC 303A receives this message (step S65) and terminates the process.

In the vehicle-mounted communication system according to Embodiment 3 having the above configuration, individual keys x, y, and z are determined for a plurality of ECUs 304A to 304C connected to a common CAN bus. The ECUs 304A to 304C store keys x, y, and z determined for themselves, and transmit MACs generated using the keys x, y, and z attached to messages. The DC 303A stores the keys x, y, and z determined for each of the ECUs 304A to 304C connected to the common CAN bus, and stores whether the MAC attached to the message transmitted to the CAN bus is correct or not. determined using any of the keys x, y, z. As a result, the plurality of ECUs 304A to 304C connected to the common CAN bus are separated from each other for security reasons, and each ECU 304A to 304C individually transmits and receives messages to and from the DC 303A, thereby improving security. can be done.

Further, in the vehicle-mounted communication system according to the third embodiment, each of the ECUs 304A to 304C uses its own keys x, y, and z to determine whether the MAC attached to the received message is correct. When DC 303A determines that the MAC attached to the received message is correct, it generates a MAC using keys x, y, and z different from the keys x, y, and z used for determination, and attaches the generated MAC. Send the message to the CAN bus. This allows DC 303A to relay message transmission/reception between ECUs 304A-304C. ECUs 304A-304C can transmit and receive messages to and from other ECUs 304A-304C via DC 303A.

Further, in the in-vehicle communication system according to the third embodiment, DC 303A determines whether the MAC attached to this message is correct before the completion of message transmission by ECUs 304A to 304C. If DC 303A determines that the MAC is incorrect, DC 303A causes ECUs 304A to 304C to discard this message by transmitting an error frame before completing the transmission of this message. As a result, each of the ECUs 304A to 304C does not need to determine whether the MAC attached to the message is correct or not, and can receive the message that was not discarded by the DC 303A without determining whether the MAC is correct or not, and use it for subsequent processing. can.

In the third embodiment, the ECUs 304A to 304C do not determine whether the MAC attached to the message is correct or not, and the DC 303A determines whether the MAC is correct or not and discards the incorrect message. do not have. As in the first and second embodiments, each of the ECUs 304A to 304C and DC 303A may determine whether the MAC is correct, and the DC 303A may transmit a notification message to the ECUs 304A to 304C when an incorrect MAC is detected. Conversely, in the in-vehicle communication system according to Embodiments 1 and 2, instead of the DC 3A transmitting the notification message, an error frame may be transmitted before the message transmission is completed, thereby discarding the unauthorized message. .

Since other configurations of the on-vehicle communication system according to Embodiment 3 are the same as those of the on-vehicle communication system according to Embodiment 1, the same parts are given the same reference numerals, and detailed descriptions thereof are omitted.

The embodiments disclosed this time are illustrative in all respects and should be considered not restrictive. The scope of the present invention is indicated by the scope of the claims rather than the meaning described above, and is intended to include all modifications within the scope and meaning equivalent to the scope of the claims.

1 vehicle 2 CGW
3A-3C DC
4A-4I ECUs
31 processing unit 31a MAC generation unit 31b MAC determination unit 31c transmission/reception processing unit 31d notification processing unit 32 storage unit 32a program 32b key storage unit 33 CAN communication unit 34 Ethernet communication unit 41 processing unit 41a MAC generation unit 41b MAC determination unit 41c transmission/reception processing Part 41d Notification processing part 42 Storage part 42a Program 42b Key storage part 43 CAN communication part 98, 99 Recording medium 303A DC
304A-304C ECUs

Claims (5)

An in-vehicle communication system comprising: a plurality of in-vehicle communication devices connected to a common communication line; and an in-vehicle communication control device connected to the common communication line and performing control related to communication of the plurality of in-vehicle communication devices. ,
An encryption key is determined for each in-vehicle communication device,
The in-vehicle communication device
a first storage unit that stores an encryption key determined for itself;
a first authenticator generating unit that generates an authenticator attached to a message to be transmitted using the encryption key stored in the first storage unit ;
a first authenticator determination unit that determines whether the authenticator attached to the received message is correct or not using the encryption key stored in the first storage unit;
has
The in-vehicle communication control device,
a second storage unit that stores an encryption key for each in-vehicle communication device;
a second authenticator determination unit that determines whether the authenticator attached to the received message is correct or not using the corresponding encryption key stored in the second storage unit ;
When the second authenticator determination unit determines that the authenticator attached to the received message is correct, another authenticator is generated using an encryption key different from the encryption key used for the determination of the authenticator. a second authenticator generating unit to generate;
a relay unit that relays message transmission/reception between in-vehicle communication devices having different security levels by attaching another authenticator generated by the second authenticator generation unit to the received message and transmitting the received message;
An in-vehicle communication system. An in-vehicle communication device connected to a common communication line,
A plurality of in-vehicle communication devices connected to the common communication line are classified into a plurality of security levels, and a common key is determined for each security level,
a storage unit that stores a common key corresponding to its own security level;
an authenticator generating unit that generates an authenticator attached to a message to be transmitted using the common key stored in the storage unit;
an authenticator determination unit that determines whether the authenticator attached to the received message is correct or not using the common key stored in the storage unit;
a notifying unit that notifies another device connected to the common communication line when the authenticator determining unit determines that the authenticator attached to the received message is incorrect ,
A message can have multiple authenticators,
The storage unit stores a common key determined for its own security level and a common key determined for a security level lower than the security level,
The authenticator generating unit uses one or more common keys stored in the storage unit to generate one or more authenticators attached to a message to be transmitted.
In-vehicle communication device. 3. The authenticator determining unit determines whether the authenticator is correct or incorrect by using one or a plurality of common keys stored in its own storage unit, among the authenticators attached to the received message. 2. The in-vehicle communication device according to 2 . A computer program that causes an in-vehicle communication device connected to a common communication line to perform processing related to communication,
A plurality of authenticators can be attached to a message transmitted and received by the in-vehicle communication device,
A plurality of in-vehicle communication devices connected to the common communication line are classified into a plurality of security levels, and a common key is determined for each security level. storing a common key determined for a security level lower than the security level in a storage unit;
generating one or more authenticators attached to a message to be transmitted using one or more common keys stored in the storage unit;
determining whether the authenticator attached to the received message is correct or not using the common key stored in the storage unit;
A computer program for executing a process of notifying other devices connected to the common communication line when it is determined that an authenticator attached to a received message is incorrect. A communication method in which an in-vehicle communication device connected to a common communication line performs processing related to communication,
A plurality of authenticators can be attached to a message transmitted and received by the in-vehicle communication device,
A plurality of in-vehicle communication devices connected to the common communication line are classified into a plurality of security levels, and a common key is determined for each security level,
storing a common key determined for its own security level and a common key determined for a security level lower than the security level in a storage unit;
generating one or more authenticators attached to a message to be transmitted using one or more common keys stored in the storage unit;
determining whether the authenticator attached to the received message is correct or not using the common key stored in the storage unit;
notifying other devices connected to the common communication line when it is determined that the authenticator attached to the received message is incorrect;
Communication method.

Images