In-vehicle network system, electronic control unit, and update processing method

BACKGROUND

00011. Technical Field

0002The present disclosure relates to a technology for working against transmission of a fraudulent frame in an in-vehicle network in which electronic control units communicate with one another.

00032. Description of the Related Art

0004In recent years, a plurality of devices called Electronic Control Units (ECUs) have been disposed in a system in motor vehicles. A network that connects the ECUs with one another is called an in-vehicle network. A plurality of standards are provided for in-vehicle networks. One of the mainstream standards is CAN (Controller Area Network) defined by ISO11898-1 (refer to “CAN Specification 2.0 Part A”, [online], CAN in Automation (CiA), [searched on Nov. 14, 2014], the Internet (URL: http://www.can-cia.org/fileadmin/cia/specifications/CAN20A.pdf)).

0005In CAN, the communication channel is formed from 2 buses. An ECU connected to the buses is referred to as a “node”. Each of the nodes connected to the buses sends and receives a message called a frame. A sender node that sends a frame applies voltages on the 2 buses so as to generate a potential difference between the buses. Thus, the sender node sends a value of “1” called “recessive” and a value of “0” called “dominant”. If a plurality of sender nodes send recessive and dominant at exactly the same time, dominant has higher priority and is sent. If the format of a received frame is abnormal, the receiver node sends a frame called an error frame. An error frame is formed from 6 consecutively sent dominant bits. By sending the error frame, the sender node or the other receiver nodes are notified of the abnormity of a frame.

0006In addition, in CAN, identifiers indicating the destination address and the source address are not present. The sender node attaches an ID called a message ID to each of frames and sends the frame (i.e., delivers a signal to the buses). Each of the receiver nodes receives only a predetermined ID (i.e., reads the signal from the buses). Furthermore, CAN employs the CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance) technique. When a plurality of nodes simultaneously send frames, arbitration using the message IDs is performed, and a frame having a smaller message ID is sent first.

0007When, in an in-vehicle network, a fraudulent node is connected to the buses and if the fraudulent node unauthorizedly sends a data frame, the vehicle body may be unauthorizedly controlled. To prevent control based on transmission of such a fraudulent frame, a technology for, in general, providing Message Authentication Code (MAC) in a data field defined by CAN and sending the frame has been developed (refer to Japanese Unexamined Patent Application Publication No. 2013-98719).

SUMMARY

0008However, since the data length of the MAC that can be stored in the data field defined by CAN is not sufficiently long, there may be a risk of, for example, a brute force attack from a fraudulent node connected to the buses against the MAC.

0009One non-limiting and exemplary embodiment provides an in-vehicle network system for increasing security against a brute force attack from a fraudulent node connected to the bus on the MAC. In addition, the present disclosure provides an electronic control unit (ECU) used in the in-vehicle network and an update processing method for performing an update process related to updating data used to generate MAC for increasing the security against a brute force attack from a fraudulent node (e.g., a MAC key).

0010In one general aspect, the techniques disclosed here feature an update processing method for updating a MAC key used to generate a message authentication code (MAC) in an in-vehicle network system including a plurality of electronic control units that each communicate a data frame with a MAC with one another via at least one bus in accordance with CAN (Controller Area Network) protocol. The method includes detecting a state of a vehicle having the in-vehicle network system mounted therein and updating a MAC key used to generate the message authentication code under the condition that the detected state of the vehicle is a predetermined state.

0011According to the present disclosure, the security against an attack from a fraudulent node connected to a bus in a network communication system that communicates information on the basis of the CAN protocol can be increased.

0012It should be noted that general or specific embodiments may be implemented as a system, an apparatus, an integrated circuit, a computer program, a storage medium, such as a computer-readable CD-ROM, or any selective combination thereof.

0013Additional benefits and advantages of the disclosed embodiments will become apparent from the specification and drawings. The benefits and/or advantages may be individually obtained by the various embodiments and features of the specification and drawings, which need not all be provided in order to obtain one or more of such benefits and/or advantages.

BRIEF DESCRIPTION OF THE DRAWINGS

0014<figref idref="DRAWINGS">FIG. 1</figref> illustrates the overall configuration of an in-vehicle network system according to a first embodiment;

0015<figref idref="DRAWINGS">FIG. 2</figref> illustrates the format of a data frame defined by the CAN protocol;

0016<figref idref="DRAWINGS">FIG. 3</figref> is the configuration diagram of an ECU according to the first embodiment;

0017<figref idref="DRAWINGS">FIG. 4</figref> illustrates an example of a received ID list;

0018<figref idref="DRAWINGS">FIG. 5</figref> illustrates an example of a determination rule;

0019<figref idref="DRAWINGS">FIG. 6</figref> illustrates an example of an ID and a data field of a data frame sent from an ECU connected to an engine;

0020<figref idref="DRAWINGS">FIG. 7</figref> illustrates an example of an ID and a data field of a data frame sent from an ECU connected to a brake;

0021<figref idref="DRAWINGS">FIG. 8</figref> illustrates an example of an ID and a data field of a data frame sent from an ECU connected to a door open/close sensor;

0022<figref idref="DRAWINGS">FIG. 9</figref> illustrates an example of an ID and a data field of a data frame sent from an ECU connected to a window open/close sensor;

0023<figref idref="DRAWINGS">FIG. 10</figref> is a flowchart illustrating an example of an update process performed by the ECU and a process related to determination of start of the update process (to be continued to <figref idref="DRAWINGS">FIG. 11</figref>);

0024<figref idref="DRAWINGS">FIG. 11</figref> is a flowchart illustrating the example of the update process performed by the ECU and the process related to determination of start of the update process (a continuation of <figref idref="DRAWINGS">FIG. 10</figref>);

0025<figref idref="DRAWINGS">FIG. 12</figref> is a flowchart illustrating an example of an update process performed by the ECU and a process related to determination of start of the update process (to be continued to <figref idref="DRAWINGS">FIG. 13</figref>);

0026<figref idref="DRAWINGS">FIG. 13</figref> is a flowchart illustrating the example of the update process performed by the ECU and the process related to determination of start of the update process (a continuation of <figref idref="DRAWINGS">FIG. 12</figref>);

0027<figref idref="DRAWINGS">FIG. 14</figref> illustrates the overall configuration of an in-vehicle network system according to a second embodiment;

0028<figref idref="DRAWINGS">FIG. 15</figref> is the configuration diagram of an ECU according to the second embodiment;

0029<figref idref="DRAWINGS">FIG. 16</figref> illustrates an example of a determination rule;

0030<figref idref="DRAWINGS">FIG. 17</figref> is a configuration diagram of a gateway;

0031<figref idref="DRAWINGS">FIG. 18</figref> illustrates an example of a transfer rule;

0032<figref idref="DRAWINGS">FIG. 19</figref> is a flowchart of an example of an update start frame transmission process performed by the gateway;

0033<figref idref="DRAWINGS">FIG. 20</figref> is a flowchart illustrating an example of an update process performed by an ECU and a process related to determination of start of the update process (to be continued to <figref idref="DRAWINGS">FIG. 21</figref>);

0034<figref idref="DRAWINGS">FIG. 21</figref> is a flowchart illustrating the example of the update process performed by the ECU and the process related to determination of start of the update process (a continuation of <figref idref="DRAWINGS">FIG. 20</figref>);

0035<figref idref="DRAWINGS">FIG. 22</figref> is a flowchart illustrating an example of an update process performed by an ECU and a process related to determination of start of the update process (to be continued to <figref idref="DRAWINGS">FIG. 23</figref>); and

0036<figref idref="DRAWINGS">FIG. 23</figref> is a flowchart illustrating the example of the update process performed by the ECU and the process related to determination of start of the update process (a continuation of <figref idref="DRAWINGS">FIG. 22</figref>).

DETAILED DESCRIPTION

0037According to an aspect of the present disclosure, an update processing method for updating a MAC key used to generate a message authentication code (MAC) in an in-vehicle network system including a plurality of electronic control units that each communicate a data frame having a MAC added thereto with one another via at least one bus in accordance with CAN (Controller Area Network) protocol is provided. The method includes detecting a state of a vehicle having the in-vehicle network system mounted therein and updating a MAC key used to generate the message authentication code under the condition that the detected state of the vehicle is a predetermined state. There is some correlation between the vehicle state and the processing load on the ECU or the amount of traffic of the bus. Accordingly, by performing the update process when the vehicle state is a state appropriate for updating, for example, the MAC key, update that is synchronized among the ECUs is available. Since the MAC key used to generate MAC can be appropriately updated, the security against a brute force attack on MAC from the fraudulent node can be increased.

0038In addition, the plurality of electronic control units may include a first electronic control unit and a second electronic control unit. The method may further include the first electronic control unit sending a data frame identified with a predetermined message ID, the first electronic control unit generating a first message authentication code that reflects the value of a transmission counter which counts the number of transmission events using the MAC key, the first electronic control unit adding the first message authentication code to the data frame to be sent, the second electronic control unit receiving the data frame identified by the predetermined message ID, the first electronic control unit generating a second message authentication code that reflects the value of a reception counter which counts the number of reception events using the MAC key, the first electronic control unit verifying whether the message authentication code added to the received data frame is the same as the second message authentication code, and resetting the transmission counter and the reception counter under the condition that the detected state of the vehicle is the predetermined state using the second electronic control unit. In this manner, the counter values used to generate MAC (the transmission counter and the reception counter) are reset. Accordingly, the security against a brute force attack on MAC from the fraudulent node can be increased.

0039In addition, the at least one bus may include a plurality of buses. Each of at least one of the plurality of electronic control units may be connected to one of the buses. In the updating a MAC key, the MAC key held by each of the at least one electronic control unit among the electronic control units is updated, and the predetermined state may be determined depending on the bus to which the each of the at least one electronic control unit is connected. In this manner, the MAC key can be updated in accordance with the state of the vehicle appropriate for the bus to which the ECU is connected.

0040In addition, the at least one bus may include a plurality of buses. Each of the plurality of buses may belong to any one of a plurality of types of group. Each of the electronic control units may be connected to any one of the buses. In the updating a MAC key, the MAC key held by each of the at least one electronic control unit among the electronic control units may be updated, and the predetermined state may be determined depending on the group to which the bus to which the each of the at least one electronic control unit is connected belongs. In this manner, the MAC key can be updated in accordance with the state of the vehicle appropriate for the group to which the bus to which the ECU is connected belongs.

0041In addition, in the updating a MAC, the MAC key may be updated if the detected state of the vehicle is the predetermined state at a timing at which a quantity of a given type counted since previous updating of the MAC key reaches a predetermined quantity. In this manner, the MAC key can be updated at predetermined intervals.

0042In addition, in the updating a MAC, if the detected state of the vehicle is not the predetermined state at a timing at which a quantity of a given type counted since previous updating of the MAC key reaches a predetermined quantity, the MAC key may be updated at a timing at which the detected state of the vehicle changes to the predetermined state. In this manner, if a predetermined period of time has elapsed since the previous updating of the MAC key, the update can be performed immediately after the state of the vehicle changes to the predetermined state.

0043In addition, the predetermined state may be a state in which the vehicle is not traveling. Furthermore, the state in which the vehicle is not traveling may be a state in which the vehicle is parking. In this manner, for example, an increase in the processing load on the ECU during traveling of the vehicle due to updating of the MAC key can be prevented.

0044According to another aspect of the present disclosure, an in-vehicle network system including a plurality of electronic control units that each communicate a data frame having a message authentication code (MAC) added thereto with one another via at least one bus in accordance with Controller Area Network (CAN) protocol is provided. The in-vehicle network system includes a first electronic control unit including one or more memories and circuitry which, in operation, holds a first MAC key used to generate the message authentication code, generates a first message authentication code using the first MAC key, adds the generated first message authentication code to a data frame identified by a predetermined message ID, sends the data frame, and updates the first MAC key under the condition that a state of a vehicle having the in-vehicle network system mounted therein is a predetermined state; and a second electronic control unit including one or more memories and circuitry which, in operation, holds a second MAC key used to generate the message authentication code, generates a second message authentication code using the second MAC key, receives a data frame identified by the predetermined message ID, verifies whether the message authentication code added to the received data frame is the same as the second message authentication code, and updates the second MAC key under the condition that the state of the vehicle is a predetermined state. In this manner, the MAC key used to generate MAC to be added to a message or used to verify a message can be appropriately updated among the ECUs that transmit CAN frames (messages). Accordingly, the security against a brute force attack on the MAC from the fraudulent node can be increased.

0045In addition, when updating the first MAC key, the circuitry of the first electronic control unit determines whether the state of the vehicle is a predetermined state when receiving a particular frame identified by a predetermined particular message ID and updates the first MAC key if the state of the vehicle is the predetermined state, and when updating the second MAC key, the circuitry of the second electronic control unit determines whether the state of the vehicle is a predetermined state when receiving a particular frame identified by a predetermined particular message ID and updates the second MAC key if the state of the vehicle is the predetermined state.

0046In this manner, each of the ECUs can easily synchronize the update timing of the MAC key using the receipt timing of the particular frame.

0047According to still another aspect of the present disclosure, an electronic control unit for operating in accordance with Controller Area Network (CAN) protocol, comprising one or more memories and circuitry which, in operation: holds a MAC key used to generate a message authentication code (MAC); generates the message authentication code using the held MAC key; and updates the held MAC key under the condition that a state of a vehicle having the electronic control unit mounted therein is a predetermined state. In this manner, the MAC key used to generate MAC to be added to a CAN frame or used to verify a CAN frame can be updated at a timing synchronized with the other ECUs that can recognize the state of the vehicle. Accordingly, the MAC key can be appropriately updated and, thus, the security against a brute force attack from the fraudulent node against the MAC in an in-vehicle network system including the ECU can be increased.

0048It should be noted that these general and specific aspects may be implemented as a system, a method, an integrated circuit, a computer program, or a computer-readable storage medium, such as a CD-ROM, or any combination of a system, a method, an integrated circuit, a computer program, and a computer-readable storage medium.

0049An in-vehicle network system including a fraud detecting ECU according to an embodiment is described below with reference to the accompanying drawings. Each of the embodiments described below is a particular example of the present disclosure. Accordingly, a value, a shape, a material, a constituent element, the positions and the connection form of the constituent elements, steps (processes), and the sequence of the steps used in the following embodiments are only examples and shall not be construed as limiting the scope of the present disclosure. In addition, among the constituent elements in the embodiments described below, the constituent element that does not appear in an independent claim is described as an optional constituent element. In addition, all the drawings are schematic illustrations and, thus, are not exactly precisely illustrated.

First Embodiment

0050According to an embodiment of the present disclosure, an in-vehicle network system <b>10</b> that achieves an update processing method for performing an update process related to updating data used to generate MAC in accordance with the state of a vehicle is described below with reference to the accompanying drawings.

0000[1.1 Overall Configuration of in-Vehicle Network System]

0051<figref idref="DRAWINGS">FIG. 1</figref> illustrates the overall configuration of the in-vehicle network system <b>10</b> according to a first embodiment. The in-vehicle network system <b>10</b> is an example of an in-vehicle network system that performs communication in accordance with the CAN protocol. In addition, the in-vehicle network system <b>10</b> is a network communication system in a motor vehicle having a variety of devices mounted therein, such as a control unit and a sensor. The in-vehicle network system <b>10</b> includes a bus <b>200</b> and nodes connected to the bus, such as ECUs <b>100</b><i>a </i>to <b>100</b><i>d </i>connected to a variety of devices. Note that the in-vehicle network system <b>10</b> further includes ECUs (not illustrated in <figref idref="DRAWINGS">FIG. 1</figref>) other than the ECUs <b>100</b><i>a </i>to <b>100</b><i>d</i>. However, for convenience of description, the following description is given with reference to only the ECUs <b>100</b><i>a </i>to <b>100</b><i>d</i>. The ECU is a unit including, for example, digital circuits, such as a processor (a microprocessor) and a memory, analog circuits, and a communication circuit. Examples of the memory includes a ROM and a RAM, which can store a control program (a computer program) executed by the processor. For example, when the processor operates in accordance with the control program (the computer program), the ECU can provide a variety of functions. Note that the computer program is formed from a plurality of instruction codes that instruct the processor to operate so that a predetermined function is provided. Hereinafter, description is given under the assumption that a fraudulent ECU that sends a fraudulent data frame may be connected to the bus <b>200</b>.

0052Each of the ECUs <b>100</b><i>a </i>to <b>100</b><i>d </i>is connected to the bus <b>200</b>. The ECUs <b>100</b><i>a </i>to <b>100</b><i>d </i>are connected to an engine <b>310</b>, a brake <b>320</b>, a door open/close sensor <b>330</b>, and a window open/close sensor <b>340</b>, respectively. Each of the ECUs <b>100</b><i>a </i>to <b>100</b><i>d </i>acquires the state of the device connected thereto (e.g., the engine <b>310</b>) and periodically sends, for example, a frame indicating the state (a data frame described below) to a network (i.e., the bus).

0053In the in-vehicle network system <b>10</b>, each of the ECUs sends and receives a frame in accordance with the CAN protocol. Frames defined by the CAN protocol include a data frame, a remote frame, an overload frame, and an error frame. For convenience of description, the following description is mainly based on a data frame and an error frame.

[1.2 Data Frame Format]

0054A data frame, which is one of the frames used in a network based on the CAN protocol, is described below.

0055<figref idref="DRAWINGS">FIG. 2</figref> illustrates the format of a data frame defined by the CAN protocol. The data frame having a standard ID format defined by the CAN protocol is illustrated in <figref idref="DRAWINGS">FIG. 2</figref>. The data frame includes an SOF (Start Of Frame) field, an ID field, an RTR (Remote Transmission Request) field, an IDE (Identifier Extension) field, a reservation bit “r”, a DLC (Data Length Code) field, a data field, a CRC (Cyclic Redundancy Check) sequence field, a CRC delimiter field “DEL”, an ACK (Acknowledgement) slot field, an ACK delimiter field “DEL”, and an EOF (End Of Frame) field.

0056The SOF field is formed from one dominant bit. When the bus is idle, the state of the bus is recessive. By changing the state of the bus from recessive to dominant using SOF, the notice of start of frame transmission is given.

0057The ID field is a 11-bit field. The ID field includes an ID (a message ID) that is a value indicating the type of data. In order to perform communication arbitration using the ID field, the design is such that if a plurality of nodes simultaneously start transmission, a frame having a lower ID value has a higher priority.

0058RTR is a value for distinguishing a data frame from a remote frame. In data frames, the RTR field is formed from one dominant bit.

0059Each of IDE and “r” is formed from one dominant bit.

0060DLC is of 4 bits. DLC indicates the length of the data field. Note that IDE, “r”, and DLC are collectively referred to as a “control field”.

0061The data field indicates the data to be transmitted, where the maximum length of the data field is 64 bits. The length can be controlled to 8 to 64 bits (multiple of 8 bits). The specification of data to be transmitted is not defined by the CAN protocol and is defined by the in-vehicle network system <b>10</b>. Accordingly, the specification of the data depends on, for example, the type of vehicle and the manufacturer (the maker).

0062The CRC sequence field is a 15-bit field. The CRC sequence is calculated using the transmitted values of SOF, the ID field, the control field, and the data field.

0063The CRC delimiter is formed from one recessive bit. The CRC delimiter is a delimiter symbol that indicates termination of the CRC sequence. Note that the CRC sequence field and the CRC delimiter field are collectively referred to as a “CRC field”.

0064The ACK slot field is a 1-bit field. The sender node sets the ACK slot to recessive and sends data. If a receiver node successfully receives the data up to the CRC sequence, the receiver node sets the ACK slot to dominant and sends the data. The dominant has a priority over the recessive. Accordingly, if the ACK slot is dominant after transmission, the sender node can be aware that any one of the receiver nodes has successfully received the data.

0065The ACK delimiter is formed from one recessive bit. The ACK delimiter is a delimiter symbol that indicates termination of ACK.

0066The EOF field is formed from 7 recessive bits. EOF indicates termination of the data frame.

[1.3 Configuration of ECU]

0067<figref idref="DRAWINGS">FIG. 3</figref> is the configuration diagram of the ECU <b>100</b><i>a</i>. The ECU <b>100</b><i>a </i>includes a frame transceiver unit <b>101</b>, a frame interpretation unit <b>102</b>, a received ID determination unit <b>103</b>, a received ID list holding unit <b>104</b>, a frame processing unit <b>105</b>, a vehicle state holding unit <b>106</b>, a determination rule holding unit <b>107</b>, a timer <b>108</b>, an update determination unit <b>109</b>, an update processing unit <b>110</b>, a MAC key holding unit <b>111</b>, a counter holding unit <b>112</b>, a MAC generating unit <b>113</b>, a frame generating unit <b>114</b>, and a data acquiring unit <b>115</b>. These constituent elements are functional constituent elements. The functions of the constituent elements are realized by the communication circuit and one of, for example, the processor that executes the control program stored in the memory and a digital circuit of the ECU <b>100</b><i>a</i>. Note that each of the ECUs <b>100</b><i>b </i>to <b>100</b><i>d </i>has substantially the same configuration as that of the ECU <b>100</b><i>a. </i>

0068The frame transceiver unit <b>101</b> sends and receives a frame to and from the bus <b>200</b> in accordance with the CAN protocol. The frame transceiver unit <b>101</b> receives a frame from the bus <b>200</b> bit by bit and transfers the frame to the frame interpretation unit <b>102</b>. In addition, the frame transceiver unit <b>101</b> sends the information in a frame received from the frame generating unit <b>114</b> to the bus <b>200</b>.

0069The frame interpretation unit <b>102</b> receives the value of the frame from the frame transceiver unit <b>101</b> and interprets the value so that the value is mapped to the fields of the frame format defined by the CAN protocol. The value that is determined to correspond to the ID field is transferred to the received ID determination unit <b>103</b>. In accordance with the result of determination sent from the received ID determination unit <b>103</b>, the frame interpretation unit <b>102</b> determines whether the value of the ID field and the data field that follows the ID field are transferred to the frame processing unit <b>105</b> or reception of the frame is stopped after the result of determination is received (i.e., interpretation of the frame is stopped). In addition, if determining that the frame does not follow the CAN protocol, the frame interpretation unit <b>102</b> sends, to the frame generating unit <b>114</b>, a notification instructing the frame generating unit <b>114</b> to send an error frame. Furthermore, upon receiving an error frame, that is, upon interpreting the frame as an error frame using the value of the received frame, the frame interpretation unit <b>102</b> discards the subsequent part of the frame. That is, the frame interpretation unit <b>102</b> stops interpreting the frame. Still furthermore, the frame interpretation unit <b>102</b> sends, to the frame processing unit <b>105</b>, the information in the ACK slot of the data frame.

0070The received ID determination unit <b>103</b> receives the value of the ID field sent from the frame interpretation unit <b>102</b> and determines whether to receive the fields subsequent to the ID field in accordance with a list of message IDs held by the received ID list holding unit <b>104</b>. The received ID determination unit <b>103</b> sends the result of the determination to the frame interpretation unit <b>102</b>.

0071The received ID list holding unit <b>104</b> holds the received ID list, which is a list of IDs (message IDs) to be received by the ECU <b>100</b><i>a</i>. <figref idref="DRAWINGS">FIG. 4</figref> illustrates an example of the received ID list.

0072The frame processing unit <b>105</b> acquires, from the MAC key holding unit <b>111</b>, a MAC key corresponding to a message ID for the message IDs and the values of the data fields of all the data frames received from the frame interpretation unit <b>102</b>. In addition, the frame processing unit <b>105</b> acquires, from the counter holding unit <b>112</b>, a counter value corresponding to the message ID. Thereafter, the frame processing unit <b>105</b> verifies the MAC included in the data field. The MAC is verified to verify the validity of the data frame (the message). More specifically, the frame processing unit <b>105</b> generates MAC through calculation in the same manner as the MAC generating unit <b>113</b> (described in more detail below) and compares the generated MAC with the MAC in the data field. If the MACs are the same, the frame processing unit <b>105</b> determines that the verification is successful. However, if MACs are not the same, the frame processing unit <b>105</b> determines that an error has occurred (i.e., the verification has failed). If it is determined that an error has occurred (i.e., the verification has failed) as a result of verification, the frame processing unit <b>105</b> notifies the frame interpretation unit <b>102</b> of the error and stops the subsequent reception process. In addition, if the frame processing unit <b>105</b> receives a frame indicating the state of the vehicle (the vehicle state), the frame processing unit <b>105</b> notifies the vehicle state holding unit <b>106</b> of the vehicle state in accordance with the frame. In addition, the frame processing unit <b>105</b> performs different processes for different ECUs in accordance with the data in the received frame. For example, the ECU <b>100</b><i>a </i>connected to the engine <b>310</b> outputs alarm sound when the vehicle travels at 30 km per hour or higher and if a door is open. The ECU <b>100</b><i>a </i>has, for example, a speaker that outputs the alarm sound. In addition, the frame processing unit <b>105</b> of the ECU <b>100</b><i>a </i>manages the data received from the other ECUs (e.g., the information indicating the states of doors) and performs, for example, a process for outputting alarm sound under a predetermined condition on the basis of the travel speed acquired from the engine <b>310</b>. The ECU <b>100</b><i>c </i>performs a process for outputting alarm sound if a door is open under the condition that the brake is not applied. The ECUs <b>100</b><i>b </i>and <b>100</b><i>d </i>perform no process. Note that the ECUs <b>100</b><i>a </i>to <b>100</b><i>d </i>may have functions other than the above-described functions. In addition, the frame processing unit <b>105</b> examines the value of the ACK slot in the data frame and determines whether the frame sent from the ECU <b>100</b><i>a </i>has been normally received by the other ECUs and sends the result of the determination to the update processing unit <b>110</b>. Note that the verification of the MAC is performed by the frame processing unit <b>105</b>. Accordingly, even when a fraudulent ECU is connected to the bus <b>200</b> and sends a fraudulent frame, verification fails and, thus, control of the vehicle based on the fraudulent frame, for example, can be prevented.

0073The vehicle state holding unit <b>106</b> holds the current vehicle state (i.e., the latest vehicle state among the vehicle states sent so far) received from the frame processing unit <b>105</b>. Particular examples of the vehicle state include “traveling”, “stopping”, and “parking”. For example, the in-vehicle network system <b>10</b> can include an ECU (not illustrated) that is connected to, for example, a sensor of the gear of the vehicle and that identifies the vehicle state from the gear position (e.g., parking, neutral, first gear, or second gear) and sends a frame indicating the identified vehicle state to the bus <b>200</b>. In addition, the in-vehicle network system <b>10</b> may include an ECU (not illustrated) that identifies the vehicle state on the basis of the information sent from a plurality of ECUs and sends a frame indicating the identified vehicle state.

0074The determination rule holding unit <b>107</b> holds a determination rule defining a correspondence between each of the vehicle states and information as to whether an update process is performed. <figref idref="DRAWINGS">FIG. 5</figref> illustrates an example of the determination rule in accordance with a vehicle state.

0075The timer <b>108</b> is a clock mechanism that counts up the time value corresponding to an elapsed time. The timer <b>108</b> sends, to the update determination unit <b>109</b>, the elapsed time from completion of the previous update process. In addition, the timer <b>108</b> resets the clock on the basis of an update process completion message received from the update determination unit <b>109</b>.

0076The update determination unit <b>109</b> acquires the current vehicle state from the vehicle state holding unit <b>106</b> if a predetermined update timing is reached on the basis of the timer <b>108</b> and determines whether the update process related to updating data used to generate a MAC (i.e., a MAC key and a counter value) is to be performed in accordance with the determination rule acquired from the determination rule holding unit <b>107</b>. More specifically, the update process includes a key update process for updating the value of the MAC key serving as a key used to generate MAC and a counter reset process for resetting the counter value that is reflected in MAC (i.e., updating the counter value to a particular value, such as zero). If it is determined that the data used to generated MAC is to be updated, the update determination unit <b>109</b> notifies the update processing unit <b>110</b> of that information. However, if it is determined that the data used to generated MAC is not updated, the update determination unit <b>109</b> waits for a change in the vehicle state. If the update process has been completed, the update determination unit <b>109</b> sends an update process completion message to the timer <b>108</b>. Thus, the timer <b>108</b> is reset. The update timing is identified on the basis of the timer <b>108</b>. The update timing is determined as the time when a predetermined period of time (e.g., 6 hours or 1 day) elapses.

0077The update processing unit <b>110</b> performs the update process in response to a notification received from the update determination unit <b>109</b>. That is, upon receiving the notification from the update determination unit <b>109</b>, the update processing unit <b>110</b> acquires the MAC key held by the MAC key holding unit <b>111</b> and caches the MAC key as an old key and generates a new key serving as a candidate of the MAC key. Thereafter, the update processing unit <b>110</b> sends the generated MAC key to the MAC key holding unit <b>111</b>. In addition, upon receiving a notification from the update determination unit <b>109</b>, the update processing unit <b>110</b> acquires the counter value held by the counter holding unit <b>112</b> and caches the counter value (i.e., temporarily stores the counter value in a storage medium). Thereafter, the update processing unit <b>110</b> instructs the counter holding unit <b>112</b> to reset the counter value. When the update processing unit <b>110</b> receives, from the frame interpretation unit <b>102</b>, a notification indicating that normal reception cannot be confirmed and if the update processing unit <b>110</b> has the caches of the MAC key and the counter value (i.e., the update processing unit <b>110</b> temporarily holds the MAC key and the counter value in a storage medium), the update processing unit <b>110</b> sends the cached key to the MAC key holding unit <b>111</b> and sends the cached counter value to the counter holding unit <b>112</b>. In addition, when the update processing unit <b>110</b> receives, from the frame interpretation unit <b>102</b>, a notification indicating that normal reception has been confirmed and if the update processing unit <b>110</b> has the caches of the MAC key and the counter value, the update processing unit <b>110</b> deletes the caches of the MAC key and the counter value (i.e., considers the temporarily stored values as being unavailable from now on by, for example, deleting the values from the storage medium). As the method for generating the MAC key, the following method is used. For example, the current MAC key is input to a predetermined one-way function (e.g., a hash function), and the derived result is defined as a candidate of a new MAC key.

0078The MAC key holding unit <b>111</b> is formed from a storage medium, such as a memory. The MAC key holding unit <b>111</b> holds, for each of the message IDs, a MAC key required for the MAC generating unit <b>113</b> and the frame processing unit <b>105</b> to calculate MAC. In response to receipt of the MAC key from the update processing unit <b>110</b>, the MAC key holding unit <b>111</b> discards the held key and holds the received key as the MAC key.

0079The counter holding unit <b>112</b> is configured so as to include a storage medium, such as a memory. The counter holding unit <b>112</b> holds, for each of the message IDs, a counter value required for the MAC generating unit <b>113</b> and the frame processing unit <b>105</b> to calculate MAC. Note that the counter value held by the counter holding unit <b>112</b> is incremented (by one) if a frame is normally sent. As this method, when a data frame is sent, the counter value is used as a transmission counter, and the number of transmission events is counted. In contrast, when a data frame is received, the counter value is used as a reception counter, and the number of reception events is counted. For example, the ECU <b>100</b><i>a </i>that sends a data frame having a message ID of “1” uses, as a transmission counter, the counter value corresponding to a message ID of “1” held by the counter holding unit <b>112</b> and increments the transmission counter each time the ECU <b>100</b><i>a </i>sends a frame. In addition, the ECU <b>100</b><i>b </i>that receives a data frame having a message ID of “1” uses, as a reception counter, the counter value corresponding to a message ID of “1” held by the counter holding unit <b>112</b> and increments the reception counter each time the sent data frame is normally received. Furthermore, upon receiving a counter value from the update processing unit <b>110</b>, the counter holding unit <b>112</b> holds the counter value. In addition, upon receiving a notification instructing a reset operation from the update processing unit <b>110</b>, the counter holding unit <b>112</b> resets the held counter value. Through the reset operation, the counter value is updated to a particular value, such as zero.

0080The MAC generating unit <b>113</b> calculates MAC by applying the MAC key held by the MAC key holding unit <b>111</b> (i.e., the MAC key corresponding to the message ID) to a value (a concatenated value) obtained by concatenating the message ID and the value of the data for the data field sent from the frame generating unit <b>114</b> and the counter value held by the counter holding unit <b>112</b> (i.e., the counter value corresponding to the message ID). That is, the MAC generating unit <b>113</b> derives the value of MAC through calculation. Thereafter, the MAC generating unit <b>113</b> sends the MAC (the result of calculation) to the frame generating unit <b>114</b>. In this example, HMAC (Hash-based Message Authentication Code) (refer to RFC2104 HMAC: Keyed-Hashing for Message Authentication) is employed as the MAC calculation method. Calculation is performed on the value obtained by applying padding to the above-described concatenated value so that the concatenated value has a predetermined block length (e.g., 4 bytes) using the MAC key. The first 4 bytes of the resultant value of the calculation is used as a MAC value. Note that the size of the MAC value and the calculation method in this example are only examples, and the size of the MAC value and the calculation method are not limited thereto. The MAC is generated so as to reflect the counter value that is incremented each time a frame is sent. Accordingly, even when data frames that contain the same data value are sent a plurality of times, the MAC provided in (i.e., appended to) the data frame changes each time the frame is sent.

0081The frame generating unit <b>114</b> configures an error frame in response to a notification that instructs transmission of the error frame and that is sent from the frame interpretation unit <b>102</b> and sends the error frame to the frame transceiver unit <b>101</b> to cause the frame transceiver unit <b>101</b> to send the error frame. In addition, the frame generating unit <b>114</b> sends, to the MAC generating unit <b>113</b>, a predetermined message ID and the value of data sent from the data acquiring unit <b>115</b> (the value of data for the data field) to receive MAC. The frame generating unit <b>114</b> configures a frame on the basis of the predetermined message ID, the sent MAC, and the sent value of data for the data field and sends the frame to the frame transceiver unit <b>101</b>. Note that the information in the frame sent from each of the ECUs <b>100</b><i>a </i>to <b>100</b><i>d </i>is described below with reference to <figref idref="DRAWINGS">FIGS. 6 to 9</figref>.

0082The data acquiring unit <b>115</b> acquires the data indicating the state of, for example, the device or the sensor connected to the ECU and sends the data to the frame generating unit <b>114</b>.

[1.4 Example of Received ID List]

0083<figref idref="DRAWINGS">FIG. 4</figref> illustrates an example of the received ID list held by each of the ECUs <b>100</b><i>a </i>to <b>100</b><i>d</i>. The example of the received ID list illustrated in <figref idref="DRAWINGS">FIG. 4</figref> is used to selectively receive frames having IDs (message IDs) of “1”, “2”, “3”, and “4” and process the received frame. For example, if the received ID list illustrated in <figref idref="DRAWINGS">FIG. 4</figref> is held by the received ID list holding unit <b>104</b> of an ECU, interpretation performed on a frame having a message ID that is not any one of “1”, “2”, “3”, and “4” by the frame interpretation unit <b>102</b> is stopped after the ID field is interpreted.

[1.5 Example of Determination Rule]

0084<figref idref="DRAWINGS">FIG. 5</figref> illustrates an example of a determination rule held by each of the ECUs <b>100</b><i>a </i>to <b>100</b><i>d</i>. The determination rule determines the state of the vehicle having the in-vehicle network system <b>10</b> mounted therein (the vehicle state) as the condition that determines whether the update process is to be performed. If the vehicle state is a predetermined state defined by the determination rule (e.g., “parking”), the performance of the update process is allowed. According to the determination rule illustrated in <figref idref="DRAWINGS">FIG. 5</figref>, if the vehicle state is “traveling” or “stopping”, the update process is not performed even when an update timing (i.e., a timing at which key updating and counter resetting are to be performed) is reached, and the processing enters a wait mode. Thereafter, if the vehicle state is changed to “parking”, the update process is performed. In addition, when the vehicle state is “parking” and if an update timing is reached, the update process is performed.

[1.6 Example of Transmission Frame of ECU Related to Engine]

0085<figref idref="DRAWINGS">FIG. 6</figref> illustrates an example of an ID (a message ID) and the data field (the data) of a data frame sent from the ECU <b>100</b><i>a </i>connected to the engine <b>310</b>. The message ID of a frame sent from the ECU <b>100</b><i>a </i>is “1”. In <figref idref="DRAWINGS">FIG. 6</figref>, the data is split into bytes with a space. The first byte represents the travel speed (km/hour), the next byte represents the counter value, and the following four bytes represent the MAC. Note that in the example illustrated in <figref idref="DRAWINGS">FIG. 6</figref>, MAC is written in hexadecimal. The travel speed represented by the first byte is in the range from a minimum of 0 (km/hour) to a maximum of 180 (km/hour). <figref idref="DRAWINGS">FIG. 6</figref> illustrates an example of the message IDs and the data in the top to bottom rows that correspond to the frames sequentially sent from the ECU <b>100</b><i>a</i>. The counter value gradually increases, and the travel speed increases from 0 km/hour in increments of 1 km/hour.

[1.7 Example of Transmission Frame of ECU Related to Brake]

0086<figref idref="DRAWINGS">FIG. 7</figref> illustrates an example of an ID (a message ID) and the data field (the data) of a data frame sent from the ECU <b>100</b><i>b </i>connected to the brake <b>320</b>. The message ID of a frame sent from the ECU <b>100</b><i>b </i>is “2”. In <figref idref="DRAWINGS">FIG. 7</figref>, the data is split into bytes with a space. The first byte represents the braking level of the brake (%), the next byte represents the counter value, and the following four bytes represent the MAC. Note that in the example illustrated in <figref idref="DRAWINGS">FIG. 7</figref>, MAC is written in hexadecimal. The braking level represented by the first byte is in the range from no braking (0(%)) to the maximum braking (100(%)). <figref idref="DRAWINGS">FIG. 7</figref> illustrates an example of the message IDs and the data in the top to bottom rows that correspond to the frames sequentially sent from the ECU <b>100</b><i>b</i>. The counter value gradually increases, and the braking level gradually decreases from 100%.

[1.8 Example of Transmission Frame of ECU Related to Door Open/Close Sensor]

0087<figref idref="DRAWINGS">FIG. 8</figref> illustrates an example of an ID (a message ID) and the data field (the data) of a data frame sent from the ECU <b>100</b><i>c </i>connected to the door open/close sensor <b>330</b>. The message ID of a frame sent from the ECU <b>100</b><i>c </i>is “3”. In <figref idref="DRAWINGS">FIG. 8</figref>, the data is split into bytes with a space. The first byte represents the door open/close state, the next byte represents the counter value, and the following four bytes represent the MAC. Note that in the example illustrated in <figref idref="DRAWINGS">FIG. 8</figref>, MAC is written in hexadecimal. The door open/close state represented by the first byte is “1” if the door is open and is “0” if the door is closed. <figref idref="DRAWINGS">FIG. 8</figref> illustrates an example of the message IDs and the data in the top to bottom rows that correspond to the frames sequentially sent from the ECU <b>100</b><i>c</i>. The counter value gradually increases, and the door open state is gradually changed to the door closed state.

[1.9 Example of Transmission Frame of ECU Related to Window Open/Close Sensor]

0088<figref idref="DRAWINGS">FIG. 9</figref> illustrates an example of an ID (a message ID) and the data field (the data) of a data frame sent from the ECU <b>100</b><i>d </i>connected to the window open/close sensor <b>340</b>. The message ID of a frame sent from the ECU <b>100</b><i>d </i>is “4”. In <figref idref="DRAWINGS">FIG. 9</figref>, the data is split into bytes with a space. The first byte represents the degree of the window opening (%), the next byte represents the counter value, and the following four bytes represent the MAC. Note that in the example illustrated in <figref idref="DRAWINGS">FIG. 9</figref>, MAC is written in hexadecimal. The degree of the window opening represented by the first byte is in the range from fully closed (0(%)) to fully open (100(%)). <figref idref="DRAWINGS">FIG. 9</figref> illustrates an example of the message IDs and the data in the top to bottom rows that correspond to the frames sequentially sent from the ECU <b>100</b><i>d</i>. The counter value gradually increases, and the window gradually opens from the fully closed state.

[1.10 Update Process]

0089Provision of MAC when a data frame is sent and an update process related to updating data that is required for generating MAC used to verify the received MAC when the data frame is received are described below. These processes are performed by each of the above-described ECUs.

0090Provision of MAC and updating related to a MAC key and the counter value used to verify the MAC for each of the messages need to be synchronously performed by the ECUs. Hereinafter, the update process related to MAC corresponding to a message ID is described with reference to an example in which the ECU <b>100</b><i>a </i>sends a data frame for ensuring synchronization of the update processes (referred to as an “update frame”) to the bus <b>200</b> and one of the other ECUs (e.g., the ECU <b>100</b><i>b</i>) receives the update frame from the bus <b>200</b>. Note that any one of the ECUs may send an update frame. For example, the ECU <b>100</b><i>a </i>that repeatedly sends a data frame having a message ID of “1” may send an update frame for synchronizing the update processes related to MAC corresponding to the message ID “1”.

0091<figref idref="DRAWINGS">FIGS. 10 and 11</figref> are flowcharts illustrating an example of the update process performed by the ECU <b>100</b><i>a </i>and a process related to determination of start of the update process. The operation performed by the ECU <b>100</b><i>a </i>is described below with reference to <figref idref="DRAWINGS">FIGS. 10 and 11</figref>.

0092The ECU <b>100</b><i>a </i>checks the elapsed time since the previous update process using the timer <b>108</b> disposed therein (step S<b>1001</b>). Thereafter, the ECU <b>100</b><i>a </i>determines whether the update timing is reached (step S<b>1002</b>). If the update timing is not reached, the ECU <b>100</b><i>a </i>repeats checking the elapsed time using the timer <b>108</b>. However, if the update timing is reached, the ECU <b>100</b><i>a </i>checks the current vehicle state (step S<b>1003</b>).

0093The ECU <b>100</b><i>a </i>determines whether to perform the update process using the current vehicle state on the basis of the determination rule held by the determination rule holding unit <b>107</b> (step S<b>1004</b>). The ECU <b>100</b><i>a </i>does not perform the update process and continues to check the vehicle state until the vehicle state changes to a state determined by the determination rule that allows the update process (step S<b>1003</b>). If the vehicle state is the state determined by the determination rule that allows the update process, the ECU <b>100</b><i>a </i>starts the update process described in step S<b>1006</b> and the subsequent steps in <figref idref="DRAWINGS">FIG. 11</figref> (step S<b>1005</b>). According to the example of the determination rule illustrated in <figref idref="DRAWINGS">FIG. 5</figref>, if the vehicle state is “traveling” or “stopping”, the ECU <b>100</b><i>a </i>waits for a change in the vehicle state to “parking” and performs the update process. However, if the vehicle state is “parking”, the ECU <b>100</b><i>a </i>immediately performs the update process (step S<b>1005</b>).

0094After the ECU <b>100</b><i>a </i>starts the update process, the ECU <b>100</b><i>a </i>caches the MAC key held by the MAC key holding unit <b>111</b> as an old key (step S<b>1006</b>). Subsequently, the ECU <b>100</b><i>a </i>generates a new key that serves as a candidate of a MAC key and stores the generated key in the MAC key holding unit <b>111</b> (step S<b>1007</b>).

0095In addition, the ECU <b>100</b><i>a </i>caches the counter value held by the counter holding unit <b>112</b> (step S<b>1008</b>). Subsequently, the ECU <b>100</b><i>a </i>resets the counter value held by the counter holding unit <b>112</b> to zero (step S<b>1009</b>).

0096Subsequently, the ECU <b>100</b><i>a </i>generates MAC using a predetermined message ID, the data value for the data field, the counter value held by the counter holding unit <b>112</b> after the resetting operation, and the newly generated MAC key held by the MAC key holding unit <b>111</b> (step S<b>1010</b>). Thereafter, the ECU <b>100</b><i>a </i>generates an update frame including the message ID, the data value for the data field, and the MAC generated in step S<b>1010</b> and broadcasts the update frame (i.e., sends the update frame to the bus <b>200</b>) (step S<b>1011</b>).

0097After sending the update frame in step S<b>1011</b>, the ECU <b>100</b><i>a </i>determines whether a node (an ECU) that has succeeded in receiving the update frame (i.e., that has normally received the update frame) is present by examining the value of the ACK slot (step S<b>1012</b>). If a node that has succeeded in receiving the update frame is present, the ECU <b>100</b><i>a </i>discards the cache (step S<b>1015</b>) and completes the update process.

0098If, as a result of the determination in step S<b>1012</b>, a node that has succeeded in receiving the update frame is not present, the ECU <b>100</b><i>a </i>causes the MAC key holding unit <b>111</b> to hold the cached old key as the MAC key again (step S<b>1013</b>). In addition, the ECU <b>100</b><i>a </i>causes the counter holding unit <b>112</b> to hold the cached counter value as the counter value again (step S<b>1014</b>). Thereafter, the ECU <b>100</b><i>a </i>generates MAC using a predetermined message ID, the data value for the data field, the counter value that is stored in the counter holding unit <b>112</b> and that is reset from the cache, and the MAC key that is stored in the MAC key holding unit <b>111</b> and that is reset from the cache (step S<b>1020</b>). Subsequently, the ECU <b>100</b><i>a </i>generates an update frame including the message ID, the data value for the data field, and the MAC generated in step S<b>1020</b> and broadcasts the update frame (i.e., sends the update frame to the bus <b>200</b>) (step S<b>1016</b>).

0099After sending the update frame in step S<b>1016</b>, the ECU <b>100</b><i>a </i>determines whether a node (an ECU) that has succeeded in receiving the update frame is present by examining the value of the ACK slot (step S<b>1017</b>). If a node that has succeeded in receiving the update frame is present, the ECU <b>100</b><i>a </i>waits for a predetermined period of time (e.g., several seconds or several minutes), and the processing performed by the ECU <b>100</b><i>a </i>returns to step S<b>1006</b> again, where the update process is performed (step S<b>1018</b>). However, if, in step S<b>1017</b>, a node that has succeeded in receiving the update frame is not present, the ECU <b>100</b><i>a </i>determines that a fatal error has occurred and, thus, stops the update process (step S<b>1019</b>). When the ECU <b>100</b><i>a </i>stops the update process, the ECU <b>100</b><i>a </i>may perform a process such as announcing the occurrence of the error or recording a log. Note that the occurrence of the error can be announced by, for example, sending a data frame indicating the occurrence of the error, displaying that information on a display, outputting audio information, or emitting light.

0100<figref idref="DRAWINGS">FIGS. 12 and 13</figref> are flowcharts of an example of the update process performed by the ECU <b>100</b><i>b </i>and a process related to determination of start of the update process. Note that among processing procedures (steps) illustrated in <figref idref="DRAWINGS">FIGS. 12 and 13</figref>, the step that is the same as that in <figref idref="DRAWINGS">FIG. 10 or 11</figref> is identified with the same reference numeral, and description of the step is not repeated as needed. In addition, each of the ECU <b>100</b><i>c </i>and the ECU <b>100</b><i>d </i>can perform an update process that is the same as that of the ECU <b>100</b><i>b</i>. The operation performed by the ECU <b>100</b><i>b </i>is described below with reference to <figref idref="DRAWINGS">FIGS. 12 and 13</figref>.

0101The ECU <b>100</b><i>b </i>checks the elapsed time since the previous update process (step S<b>1001</b>). Thereafter, the ECU <b>100</b><i>b </i>determines whether the elapsed time is the predetermined period of time and, thus, the update timing is reached (step S<b>1002</b>). If the update timing is not reached, the ECU <b>100</b><i>b </i>repeats checking the elapsed time until the elapsed time reaches the predetermined period of time. However, if the update timing is reached, the ECU <b>100</b><i>b </i>checks the current vehicle state (step S<b>1003</b>).

0102The ECU <b>100</b><i>b </i>determines whether to perform the update process on the basis of the current vehicle state in accordance with the determination rule (step S<b>1004</b>). The ECU <b>100</b><i>b </i>does not perform the update process and continues to check the vehicle state until the vehicle state changes to a state determined by the determination rule that allows the update process (step S<b>1003</b>). If the vehicle state is the state determined by the determination rule that allows the update process, the ECU <b>100</b><i>b </i>starts the update process described in step S<b>1101</b> and the subsequent steps in <figref idref="DRAWINGS">FIG. 13</figref> (step S<b>1005</b>).

0103After starting the update process, the ECU <b>100</b><i>b </i>waits until an update frame is sent over the bus <b>200</b>, that is, the update frame is received (step S<b>1101</b>).

0104Subsequently, upon receiving the update frame, the ECU <b>100</b><i>b </i>caches the MAC key held by the MAC key holding unit <b>111</b> as an old key (step S<b>1006</b>). Subsequently, the ECU <b>100</b><i>b </i>generates a new key that serves as a candidate of a MAC key and stores the generated key in the MAC key holding unit <b>111</b> (step S<b>1007</b>).

0105In addition, the ECU <b>100</b><i>b </i>caches the counter value held by the counter holding unit <b>112</b> (step S<b>1008</b>). Subsequently, the ECU <b>100</b><i>b </i>resets the counter value held by the counter holding unit <b>112</b> to zero (step S<b>1009</b>).

0106Subsequently, the ECU <b>100</b><i>b </i>generates MAC using a predetermined message ID and the data value in the data field of the received update frame, the counter value held by the counter holding unit <b>112</b> after the resetting operation, and the newly generated MAC key held by the MAC key holding unit <b>111</b> and, thereafter, verifies the MAC by comparing the generated MAC with the MAC stored in the update frame (step S<b>1102</b>). If the two MACs are the same, the verification is successful. The ECU <b>100</b><i>b </i>determines whether the verification of the MAC is successful (step S<b>1103</b>). If the verification of the MAC is successful, the ECU <b>100</b><i>b </i>sets the ACK slot to dominant so as to indicate that the reception is successful. Thereafter, the ECU <b>100</b><i>b </i>discards the cache (step S<b>1015</b>). Thereafter, the ECU <b>100</b><i>b </i>completes the update process.

0107If, as a result of the determination in step S<b>1103</b>, the verification is not successful, the ECU <b>100</b><i>b </i>causes the MAC key holding unit <b>111</b> to hold the cached old key as the MAC key again (step S<b>1013</b>). In addition, the ECU <b>100</b><i>b </i>causes the counter holding unit <b>112</b> to hold the cached counter value as the counter value again (step S<b>1014</b>). Thereafter, the ECU <b>100</b><i>b </i>waits until an update frame is sent over the bus <b>200</b>, that is, an update frame can be received (step S<b>1104</b>).

0108Subsequently, upon receiving the update frame again, the ECU <b>100</b><i>b </i>generates MAC using the message ID and the data value of the data field in the received update frame, the counter value reset in the counter holding unit <b>112</b> from the cache, and the MAC key that is reset in the MAC key holding unit <b>111</b> from the cache. Thereafter, the ECU <b>100</b><i>b </i>compares the generated MAC with the MAC included in the update frame. In this manner, the ECU <b>100</b><i>b </i>verifies the MAC (step S<b>1105</b>). The ECU <b>100</b><i>b </i>determines whether the verification of the MAC is successful (step S<b>1106</b>). If the verification is successful, the ECU <b>100</b><i>b </i>sets the ACK slot to dominant so as to indicate that the reception is successful and waits for a predetermined period of time (which is the same as the predetermined period of time in step S<b>1018</b> in transmission). Thereafter, the processing performed by the ECU <b>100</b><i>b </i>returns to step S<b>1101</b> again, where the update process is performs (step S<b>1107</b>). However, if, in step S<b>1106</b>, the verification fails, the ECU <b>100</b><i>b </i>determines that a fatal error has occurred and, thus, stops the update process (step S<b>1019</b>). When the ECU <b>100</b><i>b </i>stops the update process, the ECU <b>100</b><i>b </i>may perform a process such as announcing the occurrence of the error or recording a log.

[1.11 Effect of First Embodiment]

0109The ECU according to the first embodiment performs the update process related to updating data used to generate MAC (e.g., updating of the MAC key and resetting of the counter value) in accordance with the state of the vehicle. Since such an update process is performed as needed, the security against a brute force attack on MAC from a fraudulent ECU (a fraudulent node) connected to the bus can be increased. Note that the amount of processing performed by the ECU (the processing load) may vary in accordance with the state of the vehicle. Accordingly, for example, updating of the MAC key is performed when the vehicle is in the parking state in which the processing load is low. Thus, the updating can be efficiently performed while avoiding the occurrence of error caused by a delay of the processing, and a plurality of the ECUs (the receiver nodes corresponding to a given sender node of a frame) can be simultaneously synchronized. Note that if the synchronization is not properly performed, a frame sent from a sender node cannot be properly verified by a receiver node after that. In addition, the update process can be performed in accordance with the state of the vehicle so that the update process is avoided if the amount of traffic of the bus is relatively high due to frames sent from the ECUs (e.g., during travelling of the vehicle). There is some correlation between the vehicle state and the processing load on the ECU or the amount of traffic of the bus. Accordingly, it is effective to perform the update process when the vehicle state is an appropriate state. For example, if the update process is performed in the parking state or a state in which the vehicle is not traveling, the processing efficiency of the in-vehicle network system can be advantageously increased and, thus, an increase in the processing load on the ECU during traveling can be prevented. In addition, by appropriately performing the update process in accordance with the state of the vehicle, the occurrence of a communication error in the update process caused by a synchronization error can be prevented.

Second Embodiment

0110As another embodiment of the present disclosure, an in-vehicle network system <b>20</b> including a plurality of buses and a gateway that transfers a frame between the buses is described below with reference to the accompanying drawings. The in-vehicle network system <b>20</b> achieves an update processing method for performing an update process related to updating data used to generate MAC in accordance with the state of a vehicle. In the in-vehicle network system <b>20</b>, each of ECUs performs the update process in accordance with the state of the vehicle and an update start frame sent to a bus to which the ECU is connected.

0000[2.1 Overall Configuration of in-Vehicle Network System]

0111<figref idref="DRAWINGS">FIG. 14</figref> illustrates the overall configuration of the in-vehicle network system <b>20</b> according to a second embodiment. The in-vehicle network system <b>20</b> is achieved by partially modifying the in-vehicle network system <b>10</b> according to the first embodiment. The in-vehicle network system <b>20</b> is similar to the in-vehicle network system <b>10</b>, unless expressly specified otherwise. The in-vehicle network system <b>20</b> includes buses <b>2200</b><i>a </i>and <b>2200</b><i>b</i>, a gateway <b>2400</b>, and nodes connected to the buses, such as ECUs <b>2100</b><i>a </i>to <b>2100</b><i>d </i>connected to a variety of devices. Among the constituent elements of the in-vehicle network system <b>20</b>, the constituent element having a function that is the same as in the first embodiment is identified by the same reference numeral, and description of the constituent element is not repeated.

0112The ECUs <b>2100</b><i>a </i>to <b>2100</b><i>d </i>are connected to an engine <b>310</b>, a brake <b>320</b>, a door open/close sensor <b>330</b>, and a window open/close sensor <b>340</b>, respectively. Each of the ECUs <b>2100</b><i>a </i>to <b>2100</b><i>d </i>acquires the state of the device connected thereto (e.g., the engine <b>310</b>) and periodically sends a frame indicating the state to a network. In the in-vehicle network system <b>20</b>, each of the ECUs sends and receives a frame in accordance with the CAN protocol.

0113The gateway <b>2400</b> is one type of ECU. The gateway <b>2400</b> is connected to the bus <b>2200</b><i>a </i>to which the ECU <b>2100</b><i>a </i>and the ECU <b>2100</b><i>b </i>are connected and the bus <b>2200</b><i>b </i>to which the ECU <b>2100</b><i>c </i>and the ECU <b>2100</b><i>d </i>are connected. The gateway <b>2400</b> has a function of transferring a frame received from one bus to the other. In addition, the gateway <b>2400</b> can switch whether a received frame is transferred for each of the buses connected thereto. In addition, the gateway <b>2400</b> has a function of sending an update start frame at a timing at which the internal timer indicates a predetermined value. The update start frame is a particular frame identified by a predetermined particular message ID. The update start frame indicates start of the update process. The update start frame effectively works in order for a plurality of ECUs to synchronously perform the update process related to updating data used to generate MAC.

0114Like the in-vehicle network system <b>10</b> according to the first embodiment, the in-vehicle network system <b>20</b> can include an ECU (not illustrated) that is connected to, for example, a sensor of the gear of the vehicle and that identifies the vehicle state on the basis of the gear position (e.g., parking, neutral, first gear, or second gear) and sends a frame indicating the identified vehicle state. In addition, the in-vehicle network system <b>20</b> may include an ECU (not illustrated) that identifies the vehicle state on the basis of the information sent from a plurality of ECUs and sends a frame indicating the identified vehicle state.

[2.2 Configuration of ECU]

0115<figref idref="DRAWINGS">FIG. 15</figref> is the configuration diagram of the ECU <b>2100</b><i>a</i>. The ECU <b>2100</b><i>a </i>includes a frame transceiver unit <b>101</b>, a frame interpretation unit <b>102</b>, a received ID determination unit <b>103</b>, a received ID list holding unit <b>104</b>, a frame processing unit <b>2105</b>, a vehicle state holding unit <b>106</b>, a determination rule holding unit <b>2107</b>, an update determination unit <b>2109</b>, an update processing unit <b>110</b>, a MAC key holding unit <b>111</b>, a counter holding unit <b>112</b>, a MAC generating unit <b>113</b>, a frame generating unit <b>114</b>, a data acquiring unit <b>115</b>, and an area type holding unit <b>2116</b>. These constituent elements are functional constituent elements. The functions of the constituent elements are realized by the communication circuit of the ECU <b>2100</b><i>a </i>and one of, for example, the processor that executes the control program stored in the memory and a digital circuit. Note that each of the ECUs <b>2100</b><i>b </i>to <b>2100</b><i>d </i>has substantially the same configuration as that of the ECU <b>2100</b><i>a</i>. The constituent element having a function that is the same as in the first embodiment is identified by the same reference numeral, and description of the constituent element is not repeated.

0116The determination rule holding unit <b>2107</b> holds a determination rule defining a correspondence between each of pairs consisting of an area type (described below) and a vehicle state and information as to whether an update process is performed. <figref idref="DRAWINGS">FIG. 16</figref> illustrates an example of the determination rule in accordance with a vehicle state for each of the area types.

0117The frame processing unit <b>2105</b> is formed by partially modifying the frame processing unit <b>105</b> according to the first embodiment. The frame processing unit <b>2105</b> acquires, from the MAC key holding unit <b>111</b>, a MAC key corresponding to the message ID for a pair consisting of the message ID and the value of the data field of each of all the data frames received by the frame interpretation unit <b>102</b>. In addition, the frame processing unit <b>2105</b> acquires, from the counter holding unit <b>112</b>, the counter value corresponding to the message ID and verifies the MAC value included in the data field. If, as a result of the verification, it is determined that an error has occurred (i.e., the verification has failed), the frame processing unit <b>2105</b> notifies the frame interpretation unit <b>102</b> of the error and stops the subsequent reception process. In addition, if the frame processing unit <b>2105</b> receives a frame indicating the vehicle state, the frame processing unit <b>2105</b> notifies the vehicle state holding unit <b>106</b> of the vehicle state in accordance with the frame. In addition, if the frame processing unit <b>2105</b> receives an update start frame, the frame processing unit <b>2105</b> sends the update start frame to the update determination unit <b>2109</b>. Furthermore, the frame processing unit <b>2105</b> performs different processes for different ECUs in accordance with the data in the other received frames. For example, the ECU <b>2100</b><i>a </i>has a function of outputting alarm sound when the travel speed is higher than 30 km per hour and if the door is open. The ECU <b>2100</b><i>c </i>has a function of outputting alarm sound if no brake is applied and the door is open. The ECU <b>2100</b><i>b </i>and the ECU <b>2100</b><i>d </i>take no action. Note that the ECUs <b>2100</b><i>a </i>to <b>2100</b><i>d </i>may have a function other than the above-described functions. In addition, the frame processing unit <b>2105</b> examines the value of the ACK field of the data frame to determine whether the frame sent from the ECU <b>2100</b><i>a </i>has been normally received by the other ECUs. Thereafter, the frame processing unit <b>2105</b> sends the result of determination to the update processing unit <b>110</b>.

0118The update determination unit <b>2109</b> acquires, from the area type holding unit <b>2116</b>, the type of the bus <b>2200</b><i>a </i>to which the ECU <b>2100</b><i>a </i>is connected at the timing when the update determination unit <b>2109</b> receives, from the frame processing unit <b>2105</b>, the information indicating that the frame processing unit <b>2105</b> has received the update start frame sent from the gateway <b>2400</b>. Thereafter, the update determination unit <b>2109</b> receives the current vehicle state from the vehicle state holding unit <b>106</b> and determines whether the update process related to updating data used to generate MAC (i.e., the MAC key and the counter value) is to be performed in accordance with the determination rule acquired from the determination rule holding unit <b>107</b>. More specifically, the update process includes the key update process for updating the MAC key, which is a key used to generate MAC, and the counter reset process for resetting the counter value that is reflected in MAC (i.e., updating the counter value to a particular value, such as zero). If the update determination unit <b>109</b> determines that the data used to generate MAC is updated, the update determination unit <b>109</b> notifies the update processing unit <b>110</b> of that information. However, if the update determination unit <b>109</b> determines that the data used to generate MAC is not updated, the update determination unit <b>109</b> waits for a change in the vehicle state.

0119The area type holding unit <b>2116</b> holds the area type indicating the type of the bus <b>2200</b><i>a </i>to which the ECU including the area type holding unit <b>2116</b> (the ECU <b>2100</b><i>a</i>) is connected. The area type is used to identify which one of a plurality of groups the bus and the ECU connected to the bus belong to. The groups are created based on, for example, the property of devices to which the ECU is connected. Examples of the group include a “drive-train” group and a “body family” group. In this example, for convenience of description, the in-vehicle network system <b>20</b> includes two buses (the bus <b>2200</b><i>a </i>and the bus <b>2200</b><i>b</i>). However, the in-vehicle network system may include more buses, and some of the plurality of buses may correspond to the same area type (i.e., belong to the same group). As a particular example of the area type of a bus, the bus connected to the ECU <b>2100</b><i>a </i>that is connected to the engine <b>310</b> and the ECU <b>2100</b><i>a </i>that is connected to the brake <b>320</b> corresponds to an area type referred to as “drive-train”, and the bus connected to the ECU <b>2100</b><i>c </i>that is connected to the door open/close sensor <b>330</b> and the ECU <b>2100</b><i>d </i>that is connected to the window open/close sensor <b>340</b> corresponds to an area type referred to as “body family”. According to the example, the area type holding unit <b>2116</b> of the ECU <b>2100</b><i>a </i>holds the area type “drive-train”.

[2.3 Example of Determination Rule]

0120<figref idref="DRAWINGS">FIG. 16</figref> illustrates an example of a determination rule held by each of the ECUs <b>2100</b><i>a </i>to <b>2100</b><i>d</i>. The determination rule determines the state of the vehicle having the in-vehicle network system <b>20</b> mounted therein (the vehicle state) as the condition that allows the update process to be performed. If, in an ECU connected to a bus of a certain area type, the vehicle state is a predetermined state defined by the determination rule (e.g., “parking”) for the area type, the ECU is allowed to perform the update process. According to the determination rule illustrated in <figref idref="DRAWINGS">FIG. 16</figref>, for the ECU <b>2100</b><i>a </i>and the ECU <b>2100</b><i>b </i>connected to the bus of the type “drive train”, when the vehicle state is “traveling” or “stopping”, the update process is not performed even if an update timing at which the update process relate to, for example, updating the MAC key is to be performed is reached (that is, a timing at which the update start frame is received is reached), the ECU does not perform the update process and enters a wait mode. Thereafter, if the vehicle state changes to “parking”, the update process is performed. In addition, when the vehicle state is “parking” and if an update timing is reached, the ECU performs the update process. In addition, for the ECU <b>2100</b><i>c </i>and the ECU <b>2100</b><i>d </i>connected to the bus of the type “body family”, when the vehicle state is “traveling”, the ECU does not perform the update process even if an update timing is reached and enters a wait mode. Thereafter, if the vehicle state changes to “stopping” or “parking”, the update process is performed. In addition, when the vehicle state is “stopping” or “parking” and if an update timing is reached, the ECU performs the update process.

[2.4 Configuration of Gateway]

0121<figref idref="DRAWINGS">FIG. 17</figref> is a configuration diagram of the gateway <b>2400</b>. The gateway <b>2400</b> includes a frame transceiver unit <b>2401</b>, a frame interpretation unit <b>2402</b>, a received ID determination unit <b>2403</b>, a received ID list holding unit <b>2404</b>, a frame processing unit <b>2405</b>, a vehicle state holding unit <b>2406</b>, a determination rule holding unit <b>2407</b>, an update determination unit <b>2409</b>, an update processing unit <b>2410</b>, a MAC key holding unit <b>2411</b>, a counter holding unit <b>2412</b>, a MAC generating unit <b>2413</b>, a frame generating unit <b>2414</b>, an area type holding unit <b>2416</b>, a transfer processing unit <b>2417</b>, a transfer rule holding unit <b>2418</b>, and an update processing timer <b>2419</b>. These constituent elements are functional constituent elements. The functions of the constituent elements are realized by the communication circuit of the gateway <b>2400</b> and one of, for example, the processor that executes the control program stored in the memory and a digital circuit.

0122The frame transceiver unit <b>2401</b> is similar to the frame transceiver unit <b>101</b> of the ECU <b>2100</b><i>a</i>. The frame transceiver unit <b>2401</b> sends and receives a frame to and from each of the buses <b>2200</b><i>a </i>and <b>2200</b><i>b </i>in accordance with the CAN protocol. The frame transceiver unit <b>2401</b> receives a frame from the bus and transfers the received frame to the frame interpretation unit <b>2402</b>. In addition, the frame transceiver unit <b>2401</b> sends the information in the frame to the bus <b>2200</b><i>a </i>or <b>2200</b><i>b </i>on the basis of the bus information that indicates the destination bus and that is received from the frame generating unit <b>2414</b>.

0123The frame interpretation unit <b>2402</b> receives the value of the frame from the frame transceiver unit <b>2401</b> and interprets the value so that the value is mapped to the fields of the frame format defined by the CAN protocol. The value that is determined to correspond to the ID field is transferred to the received ID determination unit <b>2403</b>. In accordance with the result of determination sent from the received ID determination unit <b>2403</b>, the frame interpretation unit <b>2402</b> determines whether the value of the ID field and the data field that follows the ID field are transferred to the transfer processing unit <b>2417</b> and the frame processing unit <b>2405</b> or reception of a frame is stopped. In addition, if determining that the frame does not follow the CAN protocol, the frame interpretation unit <b>2402</b> sends, to the frame generating unit <b>2414</b>, a notification instructing the frame generating unit <b>2414</b> to send an error frame. Furthermore, upon receiving an error frame, the frame interpretation unit <b>2402</b> discards the subsequent part of the frame that is being received. That is, the frame interpretation unit <b>2402</b> stops interpreting the frame. Still furthermore, the frame interpretation unit <b>2402</b> sends, to the frame processing unit <b>2405</b>, the ACK slot of the update start frame. The frame interpretation unit <b>2402</b> sends a data frame other than an update start frame to the transfer processing unit <b>2417</b>.

0124The received ID determination unit <b>2403</b> receives the value of the ID field sent from the frame interpretation unit <b>2402</b> and determines whether to receive the fields subsequent to the ID field in accordance with a list of message IDs held by the received ID list holding unit <b>2404</b>. The received ID determination unit <b>2403</b> sends the result of the determination to the frame interpretation unit <b>2402</b>.

0125The received ID list holding unit <b>2404</b> is similar to the received ID list holding unit <b>104</b> of the ECU <b>2100</b><i>a</i>. The received ID list holding unit <b>2404</b> holds a received ID list, which is a list of message IDs received by the gateway <b>2400</b>.

0126The frame processing unit <b>2405</b> is similar to the frame processing unit <b>105</b> of the ECU <b>2100</b><i>a</i>. The vehicle state holding unit <b>2406</b> is similar to the vehicle state holding unit <b>106</b> of the ECU <b>2100</b><i>a</i>. The determination rule holding unit <b>2407</b> is similar to the determination rule holding unit <b>107</b> of the ECU <b>2100</b><i>a. </i>

0127The update determination unit <b>2409</b> acquires, from the area type holding unit <b>2416</b>, the types of the bus <b>2200</b><i>a </i>and the bus <b>2200</b><i>b </i>to which the gateway <b>2400</b> is connected at a timing at which the update determination unit <b>2409</b> receives the update start frame sent from the ECU including the update determination unit <b>2409</b> (the gateway <b>2400</b>) from the frame processing unit <b>2405</b>. Thereafter, the update determination unit <b>2409</b> acquires the current vehicle state from the vehicle state holding unit <b>106</b> and determines whether the update process (updating of the MAC key and resetting of the counter value) is to be performed in accordance with the determination rule acquired from the determination rule holding unit <b>107</b>. If it is determined that the update process is to be performed, the update determination unit <b>2409</b> sends a notification indicating the result of the determination to the update processing unit <b>2410</b>.

0128The update processing unit <b>2410</b> is similar to the update processing unit <b>110</b> of the ECU <b>2100</b><i>a. </i>

0129The MAC key holding unit <b>2411</b> is formed from a storage medium, such as a memory. The MAC key holding unit <b>2411</b> holds, for each of the buses and each of the message IDs, a MAC key required for the MAC generating unit <b>2413</b> and the frame processing unit <b>2405</b> to calculate MAC. In response to receipt of the notification from the update processing unit <b>2410</b>, the MAC key holding unit <b>2411</b> discards the currently held key and holds the received key as the MAC key. According to the present embodiment, description is given under the assumption that the MAC key differs from bus to bus even when the message IDs are the same.

0130The counter holding unit <b>2412</b> is configured so as to include a storage medium, such as a memory. The counter holding unit <b>2412</b> holds, for each of the buses and each of the message IDs, a counter value required for the MAC generating unit <b>2413</b> and the frame processing unit <b>2405</b> to calculate MAC. Note that the counter value held by the counter holding unit <b>2412</b> is incremented (by one) if a frame is normally sent. As this method, when a data frame is sent, the counter value is used as a transmission counter, and the number of transmission events is counted. In addition, when a data frame is received, the counter value is used as a reception counter, and the number of reception events is counted. In addition, in response to a counter value sent from the update processing unit <b>2410</b>, the counter holding unit <b>2412</b> holds the sent counter value. Furthermore, in response to a reset notification sent from the update processing unit <b>2410</b>, the counter holding unit <b>2412</b> resets the held counter value. Through the reset operation, the counter value is undated to a particular value, such as zero. According to the present embodiment, description is given under the assumption that the counter value differs from bus to bus even when the message IDs are the same.

0131The MAC generating unit <b>2413</b> calculates MAC by applying the MAC key held by the MAC key holding unit <b>2411</b> to a value (a concatenated value) obtained by concatenating the message ID and the value of the data for the data field sent from the frame generating unit <b>2414</b> and the counter value held by the counter holding unit <b>2412</b> (i.e., the counter value corresponding to the bus to which the frame is to be sent and the message ID). That is, the MAC generating unit <b>2413</b> derives the value of MAC through calculation. Thereafter, the MAC generating unit <b>2413</b> sends the MAC (the result of calculation) to the frame generating unit <b>2414</b>. In this example, HMAC (refer to RFC2104 HMAC: Keyed-Hashing for Message Authentication) is employed as the MAC calculation method. Calculation is performed on the value obtained by applying padding to the above-described concatenated value so that the concatenated value has a predetermined block length (e.g., 4 bytes) using the MAC key. The first 4 bytes of the resultant value of the calculation is used as a MAC value. Note that the size of the MAC value and the calculation method in this example are only for illustrative purposes, and the size of the MAC value and the calculation method are not limited thereto.

0132The frame generating unit <b>2414</b> configures an error frame in response to a notification that instructs transmission of the error frame and that is sent from the frame interpretation unit <b>2402</b> and sends the error frame to the frame transceiver unit <b>2401</b> to cause the frame transceiver unit <b>2401</b> to send the error frame. In addition, the frame generating unit <b>2414</b> sends, to the MAC generating unit <b>2413</b>, the message ID and the value of data field sent from the transfer processing unit <b>2417</b>. Thus, the frame generating unit <b>2414</b> receives MAC. The frame generating unit <b>2414</b> configures a frame on the basis of the message sent from the transfer processing unit <b>2417</b>, the value of the data field, and the MAC sent from the MAC generating unit <b>2413</b> and sends the frame to the frame transceiver unit <b>2401</b>. In addition, in response to a transmission instruction sent from the update processing timer <b>2419</b>, the frame generating unit <b>2414</b> sends a particular message ID predetermined for an update start frame and the value of the data field to the MAC generating unit <b>2413</b> and receives MAC. Thereafter, the frame generating unit <b>2414</b> generates an update start frame including the particular message ID, the value of the data field, and the MAC and sends the generated update start frame to the frame transceiver unit <b>2401</b>, which sends the update start frame. Upon sending the update start frame, the frame generating unit <b>2414</b> resets the timer value of the update processing timer <b>2419</b> (i.e., the value of the measured elapsed time) to zero.

0133The update processing timer <b>2419</b> is configured so as to include a clock mechanism that continuously counts up the timer value corresponding to the elapsed time. The update processing timer <b>2419</b> sequentially counts up the timer value from zero. If the timer value reaches a value indicating the elapsed time preset as a timing at which an update start frame is to be sent (e.g., 6 hours or 1 day), the update processing timer <b>2419</b> sends, to the frame generating unit <b>2414</b>, an instruction to send the update start frame. In addition, in response to a notification from the frame generating unit <b>2414</b>, the update processing timer <b>2419</b> resets the timer value to zero. Note that since the gateway <b>2400</b> is connected to a plurality of buses (the bus <b>2200</b><i>a </i>and the bus <b>2200</b><i>b</i>), the update processing timer <b>2419</b> may include a clock mechanism (a timer) for each of the buses, and the timings at which update start frames are sent to the buses may differ from each other. Alternatively, the timing at which an update start frame is sent may be determined on the basis of another method that does not use the clock mechanism. For example, a counter that is counted up each time a frame (a message) is sent may be provided. If, for example, the counter value reaches a predetermined threshold value, an update start frame may be sent and, in addition, the counter may be reset to zero.

0134The area type holding unit <b>2416</b> holds the types of the bus <b>2200</b><i>a </i>and the bus <b>2200</b><i>b </i>to which a unit including the area type holding unit <b>2416</b> (the gateway <b>2400</b>) is connected. For example, the area type holding unit <b>2416</b> hold the area type “drive-train” for the bus <b>2200</b><i>a </i>and the area type “body family” for the bus <b>2200</b><i>b. </i>

0135The transfer processing unit <b>2417</b> selects a bus used for transfer in accordance with the transfer rule held by the transfer rule holding unit <b>2418</b> on the basis of the message ID of the received frame. Thereafter, the transfer processing unit <b>2417</b> sends, to the frame generating unit <b>2414</b>, the bus information indicating the bus used for transfer and the message ID and the data sent from the frame interpretation unit <b>2402</b>. The frame to be transferred is received from the transfer source bus by the gateway <b>2400</b>. The MAC corresponding to the destination bus is attached to the frame by the gateway <b>2400</b> and is sent to the destination bus. Note that the gateway <b>2400</b> does not transfer, to other buses, an error frame received from some bus and an update start frame received from the bus to which the gateway <b>2400</b> has sent a frame.

0136The transfer rule holding unit <b>2418</b> holds the transfer rule which is the information indicating a rule regarding transfer of a frame for each of the buses. <figref idref="DRAWINGS">FIG. 18</figref> illustrates an example of the transfer rule.

[2.5 Example of Transfer Rule]

0137<figref idref="DRAWINGS">FIG. 18</figref> illustrates an example of the transfer rule held by the gateway <b>2400</b>. The transfer rule has a correspondence among the transfer source bus, the transfer destination bus, and an ID (a message ID) of a frame to be transferred. In <figref idref="DRAWINGS">FIG. 18</figref>, the symbol “*” indicates that a frame is transferred regardless of the message ID. In an example illustrated in <figref idref="DRAWINGS">FIG. 18</figref>, setting is made so that a frame received from the bus <b>2200</b><i>a </i>is transferred to the bus <b>2200</b><i>b </i>regardless of the message ID. In addition, setting is made so that among frames received from the bus <b>2200</b><i>b</i>, only a frame having a message ID of “3” is transferred to the bus <b>2200</b><i>a. </i>

[2.6 Update Process]

0138Provision of MAC when a data frame is sent and an update process related to updating data required for generating MAC used to verify MAC when a data frame is received are described below. These processes are performed by each of the above-described ECUs. The ECUs connected to each of the buses need to synchronously perform provision of MAC and updating related to a MAC key and a counter value used for verification for each of the messages. Hereinafter, as an example, an update process related to MAC corresponding to a message ID among a plurality of ECUs connected to a bus is described with reference to an example in which the gateway <b>2400</b> performs an update start frame transmission process for sending an update start frame to the bus <b>2200</b><i>a </i>and, thereafter, the ECU <b>2100</b><i>a </i>sends an update frame for examining synchronization of updating to the bus <b>2200</b><i>a </i>under a predetermined condition, and the ECU <b>2100</b><i>b </i>receives the update frame from the bus <b>2200</b><i>a. </i>

0139<figref idref="DRAWINGS">FIG. 19</figref> is a flowchart of an example of the update start frame transmission process performed by the gateway <b>2400</b>.

0140The gateway <b>2400</b> checks the elapsed time since the previous transmission of an update start frame using the update processing timer <b>2419</b> (step S<b>2001</b>). Thereafter, the gateway <b>2400</b> determines whether the elapsed time has reached a predetermined period of time and, thus, the timing at which the update start frame is to be sent is reached (step S<b>2002</b>). If the timing at which the update start frame is to be sent is not reached, the gateway <b>2400</b> repeats checking the elapsed time until the elapsed time reaches the predetermined period of time. However, if the timing at which the update start frame is to be sent is reached, the gateway <b>2400</b> generates an update start frame (step S<b>2003</b>). That is, the gateway <b>2400</b> generates MAC using the predetermined message ID, the data value of the data field, the counter value, and the MAC key and generates an update start frame having the MAC attached thereto.

0141The gateway <b>2400</b> sends the update start frame generated in step S<b>2003</b> to the bus <b>2200</b><i>a </i>(step S<b>2004</b>). The update start frame sent to the bus <b>2200</b><i>a </i>is received by the ECU <b>2100</b><i>a </i>and the ECU <b>2100</b><i>b </i>connected to the bus <b>2200</b><i>a. </i>

0142<figref idref="DRAWINGS">FIGS. 20 and 21</figref> are flowcharts illustrating an example of the update process performed by the ECU <b>2100</b><i>a </i>and a process related to determination of start of the update process. Note that among processing procedures (steps) illustrated in <figref idref="DRAWINGS">FIGS. 20 and 21</figref>, the step that is the same as that in <figref idref="DRAWINGS">FIG. 10 or 11</figref> is identified with the same reference numeral, and description of the step is not repeated as needed. The operation performed by the ECU <b>2100</b><i>a </i>is described below with reference to <figref idref="DRAWINGS">FIGS. 20 and 21</figref>.

0143The ECU <b>2100</b><i>a </i>receives the update start frame sent from the gateway <b>2400</b> (step S<b>2101</b>). Thereafter, the ECU <b>2100</b><i>a </i>verifies the MAC in the update start frame (step S<b>2102</b>). If the verification of the MAC fails, the processing is completed.

0144However, if, in step S<b>2102</b>, the verification of the MAC is successful, the ECU <b>2100</b><i>a </i>checks the area type held by the area type holding unit <b>2116</b> (step S<b>2103</b>). Subsequently, the ECU <b>2100</b><i>a </i>checks the current vehicle state (step S<b>1003</b>) and determines whether the update process is to be performed in accordance with the determination rule that corresponds to the area type checked in step S<b>2103</b> and that is held by the determination rule holding unit <b>2407</b> on the basis of the current vehicle state (step S<b>2104</b>). The vehicle state is continuously checked without performing the update process until the vehicle state changes to a state that is determined by the determination rule to perform the update process (step S<b>1003</b>). If the vehicle state is the state that is determined by the determination rule to perform the update process, the ECU <b>2100</b><i>a </i>starts the update process in step S<b>1006</b> and the following steps illustrated in <figref idref="DRAWINGS">FIG. 21</figref> (step S<b>1005</b>). According to the determination rule corresponding to “drive-train” illustrated in <figref idref="DRAWINGS">FIG. 16</figref>, when the vehicle state is “traveling” or “stopping”, the update process is performed after the ECU <b>2100</b><i>a </i>waits until the vehicle state changes to “parking”. However, when the vehicle state is “parking”, the update process is immediately performed (step S<b>1005</b>).

0145The ECU <b>2100</b><i>a </i>that has started the update process performs the update process in the same manner as the ECU <b>100</b><i>a </i>according to the first embodiment (steps S<b>1006</b> to S<b>1020</b> in <figref idref="DRAWINGS">FIG. 21</figref>).

0146<figref idref="DRAWINGS">FIGS. 22 and 23</figref> are flowcharts of an example of the update process performed by the ECU <b>2100</b><i>b </i>and a process related to determination of start of the update process. Note that among processing procedures (steps) illustrated in <figref idref="DRAWINGS">FIGS. 22 and 23</figref>, the step that is the same as that in <figref idref="DRAWINGS">FIG. 12, 13</figref>, or <b>20</b> is identified with the same reference numeral, and description of the step is not repeated as needed. The operation performed by the ECU <b>2100</b><i>b </i>is described below with reference to <figref idref="DRAWINGS">FIGS. 22 and 23</figref>.

0147The ECU <b>2100</b><i>b </i>receives the update start frame sent from the gateway <b>2400</b> (step S<b>2101</b>). Thereafter, the ECU <b>2100</b><i>b </i>verifies the MAC in the update start frame (step S<b>2102</b>). If the verification of the MAC fails, the processing is completed.

0148However, if, in step S<b>2102</b>, the verification of the MAC is successful, the ECU <b>2100</b><i>b </i>checks the area type held by the area type holding unit <b>2116</b> (step S<b>2103</b>). Subsequently, the ECU <b>2100</b><i>b </i>checks the current vehicle state (step S<b>1003</b>) and determines whether the update process is to be performed in accordance with the determination rule that corresponds to the area type checked in step S<b>2103</b> and that is held by the determination rule holding unit <b>2407</b> on the basis of the current vehicle state (step S<b>2104</b>). The vehicle state is continuously checked without performing the update process until the vehicle state changes to a state that is determined by the determination rule to perform the update process (step S<b>1003</b>). If the vehicle state is the state that is determined by the determination rule to perform the update process, the ECU <b>2100</b><i>b </i>starts the update process in the step S<b>2101</b> and the following steps illustrated in <figref idref="DRAWINGS">FIG. 23</figref> (step S<b>1005</b>). According to the determination rule corresponding to “drive-train” illustrated in <figref idref="DRAWINGS">FIG. 16</figref>, when the vehicle state is “traveling” or “stopping”, the update process is performed after the ECU <b>2100</b><i>b </i>waits until the vehicle state changes to “parking”. However, when the vehicle state is “parking”, the update process is immediately performed (step S<b>1005</b>).

0149The ECU <b>2100</b><i>b </i>that has started the update process performs the update process in the same manner as the ECU <b>100</b><i>b </i>according to the first embodiment (steps S<b>2101</b> to S<b>1019</b> in <figref idref="DRAWINGS">FIG. 23</figref>).

0150In addition, the gateway <b>2400</b> performs the above-described update process illustrated in <figref idref="DRAWINGS">FIGS. 22 and 23</figref> and the process related to determination of start of the update process in the same manner as ECU <b>2100</b><i>b. </i>

0151Note that the gateway <b>2400</b> can similarly send an update start frame to the bus <b>2200</b><i>b </i>through the update start frame transmission process (refer to <figref idref="DRAWINGS">FIG. 19</figref>). In response to the operation, the ECU <b>2100</b><i>c </i>and the ECU <b>2100</b><i>d </i>can perform the update process through the processing procedure illustrated in <figref idref="DRAWINGS">FIGS. 20 to 23</figref>.

[2.7 Effect of Second Embodiment]

0152The ECU according to the second embodiment performs the update process related to updating data used to generate MAC (e.g., updating of the MAC key and resetting of the counter value) in accordance with the area type of the bus to which the ECU is connected and the state of the vehicle. Since such an update process is performed as needed, the security against a brute force attack on MAC from a fraudulent node connected to the bus can be increased. Note that for each of the buses identified by the area type, such as “drive-train” or “body family”, a relationship between the amount of processing performed by the ECU and the vehicle state may vary. Accordingly, by determining the determination rule for each of the area types and for each of the vehicle states, a plurality of ECUs can efficiently and synchronously perform the update process. For example, updating of the MAC keys of a plurality of ECUs connected to a drive-train bus is performed during parking in which the processing load is low. In this manner, updating of the MAC key used to generate MAC and resetting of the counter value can be performed for each of ECU groups having a high correlation (for each of the area types of bus to which the ECUs are connected) at different points in time and at appropriate timings. In addition, the update process can be performed in accordance with the state of the vehicle so that the update process is avoided if the amount of traffic of the bus is relatively high due to frames sent from the ECUs (e.g., during travelling of the vehicle).

Other Embodiments

0153While the first and second embodiments have been described as examples of the technology according to the present disclosure, the technology of the present disclosure is not limited thereto. The technology of the present disclosure is applicable to other embodiments obtained by making any changes, replacement, addition, and removal in the first and second embodiments as needed. For example, the following modifications are encompassed within an aspect of the present disclosure.

0154(1) While the above embodiments have been described with reference to the ECUs <b>100</b><i>a </i>to <b>100</b><i>d </i>or the ECUs <b>2100</b><i>a </i>to <b>2100</b><i>d </i>that periodically send a frame, the frame may be sent in the form of an event that indicates a change in the state. For example, instead of periodically sending the door open/close state, the ECU may send a frame only when the door open/close state changes. Alternatively, the ECU may periodically send a frame and, in addition, the ECU may send a frame when a state change occurs.

0155(2) While the above embodiments have been described with reference to calculating MAC from the data value and the counter value, MAC may be calculated from only the data value. Alternatively, MAC may be calculated from only the counter value. Still alternatively, MAC may be calculated from the value in one of the other fields included in the data frame. In addition, the size of MAC included in a frame is not limited to 4 bytes. The size of MAC may be changed in each transmission. Similarly, the size of the counter value is not limited to 1 byte. In addition, a frame need not include the counter value at all times. Alternatively, all or part of the counter value may be included in a frame to be sent. In addition, the MAC size is not limited to a fixed size. The MAC size may vary from message ID to message ID. In addition, MAC may be sent using a plurality of frames.

0156(3) While the above embodiments have been described with reference to the counter value incremented in each transmission as the configuration that counts the number of data frame transmission events (or the number of data frame reception events), calculation performed on the counter value is not limited to increment (by one). The counter value may be incremented by two. Alternatively, the calculation is not limited to counting up by increment. The calculation may be counting down by decrement. Still alternatively, the calculation performed on the counter value may be bit shift or calculation for obtaining, as a result of calculation, an output value identified on the basis of a predetermined algorithm using the result of the previous calculation as the input value. Note that in the update process, the counter value is set to a particular value, such as zero, by resetting.

0157(4) While the above embodiments have been described with reference to the data frame that is based on the CAN protocol and that is written in the standard ID format, the data frame may be written in the extended ID format. In the case of the extended ID format, the ID (the message ID) has 29 bits made up of a base ID located at the ID position in the standard ID format and an extended ID. Accordingly, this 29-bit ID can be regarded as the ID (the message ID) used in the processes according to the above-described embodiments.

0158(5) While the above embodiments have been described with reference to HMAC serving as the algorithm used to calculate MAC, CBC-MAC (Cipher Block Chaining Message Authentication Code) or CMAC (Cipher-based MAC) may be employed. In addition, any padding method that requires the data size of a block for calculation, such as zero padding, ISO10126, PKCS#1, PKCS#5, or PKCS#7, may be employed as the padding method used to calculate MAC. In addition, to change the size to, for example, a 4-byte block, padding may be applied to any one of the topmost portion, the rearmost portion, and the middle portion. In addition, the data used to calculate MAC need not be continuous data (e.g., 4-byte continuous data). The data may be obtained by concatenating 1-bit data collected in accordance with a predetermined rule.

0159(6) While the above embodiments have been described with reference to an example of the update process that updates the MAC key and resets the counter value, only one of the updating and resetting may be performed. That is, the term “update process” may refer to a key update process that updates the value of the MAC key, which is a key used to generate MAC. Alternatively, the term “update process” may refer to the counter reset process that resets the counter value that is reflected in MAC (i.e., a process that updates the counter value to a particular value, such as zero). In addition, to update the MAC key and generate a new MAC key, calculation using a dedicated key may be employed. As described above, to update the MAC key, the current MAC key (the unupdated MAC key) is input to a predetermined one-way function, and the derived result is defined as a new MAC key (an updated MAC key). However, a method other than such a method may be employed. That is, a plurality of ECUs that synchronously update the MAC key can generate a MAC key having a value that differs from the value of the unupdated MAC key using, for example, the same algorithm.

0160(7) While the above embodiments have been described with reference to “traveling”, “stopping”, and “parking” as an example of the vehicle states, other state may be employed. For example, “fueling” indicating the state detected on the basis of open/close of the filler cap may be employed as one of the vehicle states. In addition, if the vehicle is an electric vehicle, the state “charging” detected on the basis of connection of a charging plug may be employed as one of the vehicle states. In addition, instead of employing the state “traveling”, the different states “low-speed traveling” and “high-speed traveling” may be employed as the vehicle state. Note that the vehicle state can be determined in the following manner. That is, any one of the ECUs in a vehicle sends a data frame including, for example, a sensor value acquired from one of devices, and the other ECUs receive the data frame.

0161(8) While the above embodiments have been described with reference to a MAC key held for each of the message IDs, a MAC key may be held for each of the ECUs (i.e., for each of one or more message ID groups). In addition, all the ECUs need not have the same MAC key. In addition, the ECUs connected to the same bus may have a common MAC key. Note that an ECU that sends a frame having the same message ID in a bus and an ECU that receives and verifies the frame need to hold the same MAC key. In addition, while the above embodiments have been described with reference to a counter value held for each of the message IDs, the counter value may be held for each of the ECUs (i.e., for each of one or more message ID groups). Alternatively, a common counter value may be employed for all the frames flowing in the same bus.

0162(9) While the above embodiments have been described with reference to a technique in which the MAC key and the counter value differ from bus to bus even for the same message ID, the same MAC key may be employed for different buses. In addition, even for different buses, the same counter value may be employed. Note that the ECUs that employ the same MAC key or the same counter value need to synchronously update the MAC key or synchronously reset the counter value. For example, the gateway <b>2400</b> may send the update start frame to all the buses at the same time.

0163(10) While the above embodiments have been described with reference to an example in which the ACK slot is used for the sender to determine whether an update frame has been received, an ECU that has received the update frame may send a data frame indicating successful reception instead of setting the ACK slot to dominant indicating normal reception. In particular, to synchronously perform updating of the MAC key or resetting of the counter value among a plurality of ECUs connected to different buses, it is effective that a data frame indicating successful reception is sent for the update frame. Note that in such a case, the gateway transfers an update frame and a data frame indicating successful reception between the buses.

0164(11) The determination rule described in the above embodiments is only an example. The values may be changed to different values. Alternatively, a plurality of determination rules may be employed. The determination rule may have an additional condition (e.g., a condition that a predetermined period of time has elapsed since the previous update process) if the condition for performing the update process is a predetermined vehicle state (e.g., a parking state). In addition, the determination rule may be set when the ECUs and the gateway are shipped or the vehicle body having the in-vehicle network system mounted therein is shipped. Alternatively, the determination rule may be set on the basis of communication with the outside or using one of a variety of recording media or one of some tools.

0165(12) Instead of sending the update start frame described in the above embodiments by the gateway <b>2400</b>, any one of the ECUs <b>2100</b><i>a </i>to <b>2100</b><i>d </i>may send the update start frame. Alternatively, the in-vehicle network system may include an ECU dedicated to send an update start frame, and the ECU may send an update start frame. In addition, for each of the message IDs that are targets of the update process, the update start frame may include identification information regarding the message ID and may be sent. In this case, an ECU that has received the update start frame can perform the update process corresponding to the message ID (updating of the MAC key corresponding to the message ID and resetting of the counter value corresponding to the message ID). Alternatively, if an update start frame is sent once, all the ECUs that has received the update start frame may update all the held MAC keys and reset all the held counter values.

0166(13) While the above embodiments have been described with reference to a technique in which the elapsed time is sequentially checked in checking the elapsed time based on the timer <b>108</b> by the ECU (steps S<b>1001</b> and S<b>1002</b>) and in checking the elapsed time based on the update processing timer <b>2419</b> by the gateway (steps S<b>2001</b> and S<b>2002</b>), a technique in which for example, the timers send the information indicating the elapse of a predetermined period of time may be employed. In addition, while the above embodiments have been described with reference to the update timing determined as a timing at which a predetermined period of time has elapsed in the timer <b>108</b>, the update timing may be a timing at which a quantity of a given type measured by any counter since the previous update timing or the previous update process reaches a predetermined quantity. For example, the update timing may be a timing at which a counter value serving as the transmission counter or the reception counter exceeds a threshold value that is smaller than the predetermined highest value. In addition, while the above embodiments have been described with reference to the update start frame transmission timing determined as a timing at which the timer value of the update processing timer <b>2419</b> reaches a value indicating the predetermined elapsed time, the update start frame transmission timing may be a timing at which a quantity of a given type measured by any counter since the previous update start frame transmission timing (i.e., the timing at which the update process has previously been performed) reaches a predetermined quantity.

0167(14) The area types described in the above embodiments are only an example of groups. In addition to “drive-train” and “body family”, the area types may include, but not limited to, “power-train”, “driving safety control system”, “external communication system”, and “AV processing system” in accordance with the properties of the ECUs connected to the bus or the properties of devices connected to the ECUs. In addition, a bus or an ECU may belong to a plurality of groups. Accordingly, the ECU may hold a plurality of area types. Alternatively, in the determination rule, the vehicle state, which is a condition for performing the update process, may be determined so that an area type and a bus have a one-to-one correspondence (i.e., the buses are individually identified).

0168(15) The functional partition among the functional constituent elements of the devices, such as the ECU, according to the above-described embodiments is only an example. The functional partition can be changed. For example, the functional partition among the update processing unit, the update determination unit, and the functional constituent elements related to the update processing unit and the update determination unit is only an example. Accordingly, these constituent elements may be integrated into and configured as an update processing unit that performs the update process (e.g., updating of the MAC key held by the MAC key holding unit) under the condition that the vehicle state is a predetermined state.

0169(16) While the above embodiments have been described with reference to an ECU that verifies MAC upon receiving a data frame communicated among the ECUs, the in-vehicle network system may include an ECU dedicated to MAC verification that verifies the MACs provided to all the data frames. The ECU dedicated to MAC verification holds the MAC keys and the counter values corresponding to all the message IDs. If the ECU dedicated to MAC verification determines that an error has occurred as a result of verification (i.e., the verification failed), the ECU dedicated to MAC verification may send an error frame in order to prevent the other ECUs from receiving the data frame.

0170(17) While the above embodiments have been described with reference to each of the ECUs that sends a data frame, the in-vehicle network system may include an ECU that only receives a data frame without sending a data frame. Conversely, the in-vehicle network system may include an ECU that only sends a data frame without receiving any data frame.

0171(18) The CAN protocol according to the above-described embodiments may be a CAN protocol that adopts a broad definition including a derivative protocol, such as TTCAN (Time-Triggered CAN) or CANFD (CAN with Flexible Data Rate).

0172(19) The MAC key holding unit and the counter holding unit according to the above-described embodiments may be stored in a register of the hardware called a CAN controller or the firmware running in a microcomputer that is connected to a CAN controller.

0173(20) While the above embodiments have been described with reference to the ECUs each being a unit including, for example, a digital circuit (e.g., a processor and a memory), an analog circuit, and a communication circuit, the ECU may include other hardware constituent elements, such as a hard disk unit, a display, a keyboard, and a mouse. Alternatively, the function may be realized by dedicated hardware (e.g., a digital circuit) instead of being realized by software, that is, a control program stored in a memory and executed by a processor.

0174(21) Some or all of the constituent elements that constitute each of the units of the above-described embodiments (e.g., the ECU) may be formed from a single system LSI (Large Scale Integration). A system LSI is a super multifunctional LSI produced by integrating a plurality of constituent units into one chip. More specifically, the system LSI is a computer system including a microprocessor, a ROM, and a RAM. The RAM has a computer program stored therein. The microprocessor operates in accordance with the computer program and, thus, the system LSI realizes the function. Alternatively, the units of the constituent element that constitutes each of the above-described devices may be individually formed as one chip, or the one chip may be formed so as to include some or all of the units. Note that although the term “system LSI” is used, the system LSI may be referred to as an “IC”, an “LSI”, a “super LSI”, or an “ultra LSI” depending on the integration degree. The method for integrating the units is not limited to making an LSI. The method for integrating the units may be realized by a dedicated circuit or a general-purpose processor. Alternatively, an FPGA (Field Programmable Gate Array) that is programarable after the LSI is produced or a reconfigurable processor that allows the circuit cells in the LSI to be re-connected and allows the settings to be reconfigured may be employed. Still alternatively, if a new technology that replaces an LSI is developed with the advancement of semiconductor technology or another related technology, the functional blocks may be integrated by using such a technology. Note that there is a possibility of applying biotechnology.

0175(22) Some or all of the constituent elements that constitute each of the above-described units may be formed from an IC card or a single module removable from the device. The IC card or the module is a computer system formed from, for example, a microprocessor, a ROM, and a RAM. The IC card or the module may include the above-described super multifunctional LSI. When the microprocessor operates in accordance with the computer program, the IC card or the module provides its function. The IC card or the module may be tamper resistant.

0176(23) According to an aspect of the present disclosure, the above-described fraud detection method may be provided. The method may be represented by a computer program realized by a computer or a digital signal formed from the computer program. According to another aspect of the present disclosure, the computer program or the digital signal recorded in a computer-readable storage medium, such as a flexible disk, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, a BD (Blu-ray (trade name) Disc), or a semiconductor memory, may be provided. In addition, the above-described digital signal recorded in such a storage medium may be provided. According to another aspect of the present disclosure, the computer program or the digital signal may be transmitted via an electric communication network, a wireless or wired communication network, a network represented by the Internet, or data broadcasting. According to another aspect of the present disclosure, a computer system including a microprocessor and a memory is provided. The memory may store the computer program therein, and the microprocessor may operate in accordance with the computer program. Furthermore, the present disclosure may be realized by another independent computer system by recording the program or the digital signal in the storage medium and transferring the storage medium or transferring the program or the digital signal via, for example, the above-mentioned network.

0177(24) The aspect realized by combining the constituent elements described in the above-described embodiments and the modifications in any way is encompassed within the scope of the present disclosure.

0178The present disclosure is available in order to increase the security against an attack from a fraudulent ECU in an in-vehicle network system.