WO2018173603A1 - 更新処理方法、車載ネットワークシステムおよび電子制御ユニット - Google Patents

更新処理方法、車載ネットワークシステムおよび電子制御ユニット Download PDF

Info

Publication number
WO2018173603A1
WO2018173603A1 PCT/JP2018/006140 JP2018006140W WO2018173603A1 WO 2018173603 A1 WO2018173603 A1 WO 2018173603A1 JP 2018006140 W JP2018006140 W JP 2018006140W WO 2018173603 A1 WO2018173603 A1 WO 2018173603A1
Authority
WO
WIPO (PCT)
Prior art keywords
electronic control
mac
vehicle
key
update
Prior art date
Application number
PCT/JP2018/006140
Other languages
English (en)
French (fr)
Inventor
勇二 海上
崇光 佐々木
芳賀　智之
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from JP2018006869A external-priority patent/JP2018160888A/ja
Application filed by パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Publication of WO2018173603A1 publication Critical patent/WO2018173603A1/ja

Links

Images

Definitions

  • This disclosure relates to an update processing method, an in-vehicle network system, and an electronic control unit.
  • ECU Engine Control Unit
  • CAN Controller
  • a bus used as a communication line is composed of two cables (twisted pair cables), and an ECU connected to the bus is called a node.
  • Each node connected to the bus transmits and receives a message called a frame.
  • a node that transmits a frame (hereinafter also referred to as a transmission node) applies a voltage to two cables, and a “1” value called “recessive” corresponding to the presence or absence of a potential difference generated between the two cables and “dominant” “ By transmitting a value of 0 ′′, the frame data is transmitted as binary data converted into a binary number.
  • a node that receives a frame (hereinafter also referred to as a receiving node) transmits a frame called an error frame that starts with, for example, a continuous 6-bit dominant when the format of the received frame is abnormal.
  • the receiving node can notify the transmitting node and other receiving nodes of the abnormality of the frame by transmitting the error frame.
  • each transmitting node transmits each frame with an ID called a message ID, and each receiving node receives only a frame including a predetermined message ID.
  • the CSMA / CR Carrier Sense Multiple Access / Collision Resolution
  • arbitration is performed based on the message ID, and frames with small message ID values are preferentially transmitted. Is done.
  • CAN does not have a security function that assumes a case where an illegal frame is transmitted. Therefore, an unauthorized node can connect to a CAN bus and transmit an unauthorized frame, thereby allowing unauthorized control of the body of a car on which the CAN is mounted.
  • Patent Document 1 discloses a method of transmitting a message authentication code embedded in a data field in a data frame used for CAN communication.
  • the message authentication code is also called MAC (Message Authentication Code). Then, following the normal data frame, by transmitting a data frame in which the MAC is embedded in the data field of the data frame, transmission of an illegal frame can be prevented.
  • MAC Message Authentication Code
  • RFC2104 HMAC Keyed-Hashing for Message Authentication
  • An update processing method is a key update processing method used in an in-vehicle network system that includes a plurality of electronic control units and is mounted on a vehicle, and includes at least one of the plurality of electronic control units.
  • the acquisition step for acquiring travel information that is transmitted from the vehicle, which is information related to the travel of the vehicle, and the state related to the travel of the vehicle obtained from the travel information is a predetermined state
  • a key update step for updating a MAC key (MAC: Message Authentication Code) that is a key used to generate a message authentication code that is a message authentication code that is added to data to be exchanged and that is a code for preventing falsification. .
  • the update processing method and the like of the present disclosure can efficiently and reliably update the key used in the in-vehicle network system. Thereby, the vehicle-mounted network system of a safe state can be maintained.
  • FIG. 1 is a block diagram showing a configuration of an in-vehicle network system in the embodiment.
  • FIG. 2 is a block diagram showing an example of the configuration of the key update management apparatus shown in FIG.
  • FIG. 3 is a diagram illustrating an example of the overall configuration of the in-vehicle network system according to the embodiment.
  • FIG. 4 is a diagram showing a format of a data frame of the CAN protocol.
  • FIG. 5 is a diagram illustrating an example of a MAC transmission method in CAN communication.
  • FIG. 6 is a diagram illustrating an example of a MAC transmission method in Ethernet (registered trademark) communication.
  • FIG. 7 is a block diagram illustrating a functional configuration of the ECU according to the embodiment.
  • FIG. 1 is a block diagram showing a configuration of an in-vehicle network system in the embodiment.
  • FIG. 2 is a block diagram showing an example of the configuration of the key update management apparatus shown in FIG.
  • FIG. 3 is a diagram illustrating an
  • FIG. 8 is a diagram illustrating an example of the reception ID list in the embodiment.
  • FIG. 9A is a diagram illustrating an example of a determination rule in the embodiment.
  • FIG. 9B is a diagram illustrating an example of a determination rule in the embodiment.
  • FIG. 10 is a diagram illustrating an example of a message ID and data transmitted by the ECU connected to the engine in the embodiment.
  • FIG. 11 is a diagram illustrating an example of a message ID and data transmitted by the ECU connected to the brake in the embodiment.
  • FIG. 12 is a diagram illustrating an example of a message ID and data transmitted by the ECU connected to the door opening / closing sensor according to the embodiment.
  • FIG. 13 is a diagram illustrating an example of a message ID and data transmitted by the ECU connected to the window opening / closing sensor according to the embodiment.
  • FIG. 14 is a diagram illustrating an example of a message ID and data transmitted by the ECU connected to the GPS sensor in the embodiment.
  • FIG. 15 is a flowchart illustrating an update processing method according to the embodiment.
  • FIG. 16 is a flowchart showing the detailed process of step S11 shown in FIG.
  • FIG. 17 is an example of a flowchart showing the detailed process of step S12 shown in FIG.
  • FIG. 18 is another example of a flowchart showing the detailed process of step S12 shown in FIG.
  • the data field in the data frame used for CAN communication is as small as 8 bytes, and it is difficult to secure sufficient attack resistance with the size of the MAC embedded in the data field.
  • the MAC key used for generating the MAC (hereinafter also referred to as the MAC key) in order to increase the resistance of the brute force attack to the MAC embedded in the data field.
  • the key is updated regularly, the key is updated regardless of the operation of the car. In other words, when updating the key periodically, the key is updated even if almost no frame is transmitted / received in the CAN, so that the key update process may be a burden on the in-vehicle network system.
  • the present disclosure has been made in view of the above-described circumstances, and provides an update processing method and the like that can efficiently and reliably update a key used in an in-vehicle network system.
  • An update processing method is a key update processing method used in an in-vehicle network system that includes a plurality of electronic control units and is mounted on a vehicle, and includes at least one of the plurality of electronic control units.
  • MAC key MAC: Message Authentication Code
  • the update process including the key update process of the MAC key and the reset process of the counter is executed in accordance with the travel distance and / or the state of the vehicle, so that the update process is appropriately performed according to the operation of the vehicle.
  • the predetermined state may be a state in which the vehicle travel distance obtained from the travel information and the travel distance of the vehicle from the previous update of the MAC key exceeds a threshold value.
  • the predetermined state may be a state in which a predetermined time has elapsed since the last update of the MAC key and the vehicle state obtained from the travel information is parked.
  • all of the plurality of electronic control units generate a new MAC key using the MAC key at the same timing that satisfies the condition, whereby the MAC key is changed to the new key. You may update to a new MAC key.
  • one of the plurality of electronic control units generates a new MAC key using the MAC key when the condition is satisfied, and the one electronic control unit includes: A distribution step of updating the MAC key to the new MAC key by distributing the generated new MAC key to all of the plurality of electronic control units other than the one electronic control unit. .
  • the in-vehicle network is a CAN (Controller Area Network) in which the plurality of electronic control units are connected to a bus, and the update processing method is a first electronic control that is one of the plurality of electronic control units.
  • the unit transmits a data frame as the data and a verification data frame using the data field of the data frame as the message authentication code added to the data via the bus according to the CAN protocol.
  • the first electronic control unit uses the MAC key for a value obtained by combining at least the ID for identifying the data frame and the number of transmissions of the data frame counted by the transmission counter.
  • a MAC generating step for generating the message authentication code and in the receiving step, the second electronic control unit includes the message authentication code obtained by receiving the verification data frame and the received data frame.
  • a verification step of verifying the identity of the message authentication code generated using the MAC key with respect to a value obtained by combining at least the corresponding ID and the reception count of the data counted by the reception counter may be included.
  • the in-vehicle network system is a network in which the plurality of electronic control units are connected by a LAN (Local Area Network), and the update processing method is one of the plurality of electronic control units.
  • a second electronic control unit that is at least one of a plurality of electronic control units other than the unit may include a reception step of receiving the data transmitted by the first electronic control unit.
  • the first electronic control unit further includes a value obtained by combining at least the transmission source address and the transmission destination address added to the data and the number of transmissions of the data counted by the transmission counter.
  • a MAC generation step of generating the message authentication code using the MAC key wherein in the reception step, the second electronic control unit receives the data including the message authentication code in a payload portion;
  • the MAC key is used to generate a value that combines at least the message authentication code, the source address and destination address added to the received data, and the number of times the data is counted by the reception counter. Verification step to verify the identity of the message authentication code Or it may be you.
  • the update processing method may further include a reset step for resetting the transmission counter and the reception counter as the condition.
  • the plurality of electronic control units may belong to one of a plurality of groups classified according to the vehicle control application, and the predetermined state in each of the plurality of groups may be determined for each of the plurality of groups. .
  • an in-vehicle network system is an in-vehicle network system that includes a plurality of electronic control units and is mounted on a vehicle, the vehicle being transmitted from at least one of the plurality of electronic control units.
  • An acquisition unit that acquires travel information that is information related to the travel of the vehicle, and is added to data exchanged in the in-vehicle network system on condition that the state related to travel of the vehicle obtained from the travel information is a predetermined state.
  • An update processing unit that updates a MAC key (MAC: Message Authentication Code) that is a key used to generate a message authentication code that is a message authentication code and is a code for preventing falsification.
  • MAC key MAC: Message Authentication Code
  • An electronic control unit is an electronic control unit connected to an in-vehicle network system mounted on a vehicle, and includes a CPU and a memory, and the CPU includes a plurality of electronic control units.
  • Travel information that is information relating to the travel of the vehicle transmitted from at least one is acquired and stored in the memory, and the CPU is in a state related to the travel of the vehicle obtained from the travel information stored in the memory.
  • a MAC key (MAC) that is a key used to generate a message authentication code that is a message authentication code that is added to data exchanged in the in-vehicle network system and that is a code for preventing falsification, provided that it is in a predetermined state. : Message (Authentication Code) is updated.
  • MAC Message Authentication Code
  • FIG. 1 is a block diagram showing a configuration of an in-vehicle network system 100 according to the present embodiment.
  • FIG. 2 is a block diagram showing an example of the configuration of the key update management apparatus shown in FIG.
  • the in-vehicle network system 100 in the present embodiment has a plurality of electronic control units (ECUs) and is mounted on a vehicle.
  • ECUs electronice control units
  • an in-vehicle network system 100 includes a key update management device 10 and a plurality of ECUs.
  • a plurality of ECUs and a plurality of ECUs and a key update management device are connected by a network.
  • the network may be the above-mentioned CAN, or a LAN such as Ethernet (registered trademark).
  • the key update management device 10 performs key update processing at an appropriate frequency according to the operation of the vehicle.
  • the key update management device 10 may be a gateway or one of a plurality of ECUs.
  • the key update management device 10 includes an acquisition unit 11, a key update unit 12, and a key update process determination unit 13.
  • the acquisition unit 11 acquires travel information that is information regarding the travel of the vehicle transmitted from at least one of the plurality of electronic control units.
  • the travel distance of the vehicle can be obtained from the travel information.
  • the key update process determination unit 13 determines whether or not the key update unit 12 satisfies a condition for executing the key update process.
  • the key update unit 12 is a MAC added to data exchanged in the in-vehicle network system 100 and is a code for preventing falsification, on condition that the state relating to the traveling of the vehicle obtained from the traveling information is a predetermined state.
  • the MAC key that is the key used for generating the password is updated. Note that the key update unit 12 may reset the transmission counter and the reception counter on condition that the state relating to the traveling of the vehicle obtained from the traveling information is a predetermined state.
  • the key update unit 12 may perform key update processing for updating the MAC key to all of the plurality of ECUs at the same timing by notifying the timing that satisfies the condition for executing the key update processing.
  • the key update unit 12 distributes a new MAC key generated at a timing that satisfies the condition for executing the key update process to all of the plurality of ECUs, thereby updating the MAC key to all of the plurality of ECUs at the same timing.
  • the key update process to be performed may be performed. Note that it is not essential to notify the timing when the condition for executing the key update process is satisfied. If it is CAN, even if all the plurality of ECUs independently determine the timing, all the plurality of ECUs are at the same timing. This is because it will be updated.
  • FIG. 3 is a diagram showing an example of the overall configuration of the in-vehicle network system 100a in the present embodiment.
  • the in-vehicle network system 100a is an example of the in-vehicle network system 100 described above.
  • a plurality of electronic control units ECU 111, ECU 121, ECU 131, ECU 141, ECU 151, ECU 161, ECU 171, ECU 181, ECU 182, ECU 184, ECU 191 and gateway 101 are connected via an in-vehicle network.
  • the in-vehicle network may be CAN, Ethernet (registered trademark), or a mixture of CAN and Ethernet.
  • the in-vehicle network is connected with, for example, an engine 110, a transmission 120, and an unillustrated drive system ECU related to control of a motor, fuel, and a battery.
  • an ECU 111 for the engine 110 and an ECU 121 for the transmission 120 are connected to the in-vehicle network.
  • a chassis ECU related to turning and stopping such as the brake 130 and the steering 140 is connected to the in-vehicle network.
  • an ECU 141 for the steering wheel 140 and an ECU 141 for the steering wheel 140 are connected to the vehicle-mounted network.
  • the in-vehicle network is connected to an automatic brake 150, a lane keeping device 160, and a safety comfort function system ECU such as an inter-vehicle distance function, a collision prevention function, and an air bag (not shown).
  • a safety comfort function system ECU such as an inter-vehicle distance function, a collision prevention function, and an air bag (not shown).
  • an ECU 151 for the automatic brake 150 and an ECU 161 for the lane keeping device 160 are connected to the in-vehicle network.
  • a communication system ECU related to the inter-vehicle communication device 170 or the like is connected to the in-vehicle network.
  • an ECU 171 for the vehicle-to-vehicle communication device 170 is connected to the in-vehicle network.
  • the inter-vehicle communication device 170 acquires content data from other vehicles.
  • the ECU 171 performs operation processing such as automatic driving using the acquired content data.
  • an infotainment ECU such as the head unit 180 is connected to the in-vehicle network.
  • an ECU 181 for the head unit 180 is connected to the in-vehicle network. Note that the ECU 181 for the head unit 180 may not be provided, and the head unit 180 may be directly connected to the in-vehicle network without going through the ECU 181.
  • an ECU 191 for an ITS (Intelligent Transport Systems) device 190 that is an intelligent transportation system is connected to the in-vehicle network.
  • an ECU 191 for the ITS device 190 is connected to the in-vehicle network.
  • the ITS device 190 receives not only road information but also map data on which static features such as roads and buildings are placed from an external server.
  • the ITS device 190 transmits sensor information, position information by GPS (Global Positioning System), camera image information, and the like to an external server, so that the external server can check road conditions and the like.
  • a window opening / closing sensor 183, a door opening / closing sensor 185, a GPS sensor 187, and the like are connected to the in-vehicle network.
  • an ECU 182 for the window opening / closing sensor 183, an ECU 184 for the door opening / closing sensor 185, and an ECU 186 for the GPS sensor 187 are connected to the in-vehicle network.
  • various sensors (not shown) and image information of cameras are also connected to the in-vehicle network.
  • Such a plurality of electronic control units acquire the status of the connected ones and transmit a frame representing the periodically acquired status to the in-vehicle network.
  • FIG. 4 is a diagram showing a format of a data frame of the CAN protocol. Here, a data frame in a standard ID format in the CAN protocol is shown.
  • the data frame includes a Start Of Frame (hereinafter SOF), an ID field, a Remote Transmission Request (hereinafter RTR), an Identifier Extension (hereinafter IDE), a reserved bit (r), and a data length code.
  • SOF Start Of Frame
  • RTR Remote Transmission Request
  • IDE Identifier Extension
  • r reserved bit
  • DLC data length code
  • DLC data field
  • CRC Cyclic Redundancy Check
  • ACK Acknowledgment
  • ACK delimiter right DEL in the figure
  • EOF end-of-frame
  • SOF is a 1-bit dominant. It is recessive when the bus is idle. The transmitting node notifies the start of frame transmission by changing the bus from recessive to dominant.
  • ID is a value of 11 bits and indicates the type of data frame.
  • the data frame type here refers to, for example, the content of data or a transmission node that is the transmission source of the data frame.
  • the ID is also used for communication arbitration when a plurality of nodes simultaneously start transmitting data frames on the same network. More specifically, a data frame having a smaller ID is prioritized and transmitted.
  • RTR is a 1-bit dominant and indicates a data frame.
  • IDE and r are 1-bit dominants, respectively.
  • DLC is a 44-bit value indicating the length of the following data field.
  • the data field is a portion of data transmitted with a maximum length of 64 bits and is a payload of a data frame.
  • the length can be adjusted in units of 8 bits.
  • the specification regarding the allocation to the portion of data to be transmitted depends on at least one of the vehicle type and the manufacturer.
  • the CRC sequence is 15 bits long and indicates a value calculated from the transmission values of the SOF, ID field, control field, and data field.
  • the receiving node determines the presence / absence of abnormality by comparing the result calculated from the received values of the SOF, ID field, control field, and data field for each data frame with the value of the CRC sequence.
  • the CRC delimiter is a 1-bit recessive delimiter that represents the end of the CRC sequence.
  • the ACK slot is 1 bit long, and the transmitting node transmits recessive in this part. If the receiving node has successfully received the CRC sequence, it transmits a dominant in this part. In the CAN standard, the dominant is given priority in the dominant and recessive transmitted simultaneously. Therefore, in the in-vehicle network system in which communication is normally performed, the bus is in a dominant state during transmission of the ACK slot.
  • the ACK delimiter is a 1-bit recessive delimiter that represents the end of the ACK slot.
  • EOF is 7 bits long and indicates the end of the data frame.
  • FIG. 5 is a diagram illustrating an example of a MAC transmission method in CAN communication.
  • FIG. 5A shows a data frame used for CAN communication, which is the same as FIG.
  • FIG. 5B shows a verification data frame used for MAC transmission.
  • the MAC is transmitted by a verification data frame in which the data field of the normal data frame shown in FIG. That is, following the normal data frame, a verification data frame with the data field in the data frame as MAC is transmitted.
  • a first electronic control unit which is one of a plurality of electronic control units, transmits a data frame as data and data of a data frame as MAC added to the data via a bus according to the CAN protocol.
  • a verification data frame with the field MAC is transmitted.
  • the first electronic control unit uses a MAC key for a value obtained by combining at least the ID for identifying the data frame and the number of transmissions of the data frame counted by the transmission counter. Generate a MAC.
  • the second electronic control unit which is at least one of the plurality of electronic control units other than the first electronic control unit among the plurality of electronic control units, transmits the data frame transmitted by the first electronic control unit and the verification A data frame is received via the bus. Then, the second electronic control unit applies at least a value obtained by combining the MAC obtained by receiving the verification data frame, the ID corresponding to the received data frame, and the number of times of reception of the data counted by the reception counter. The identity with the MAC generated using the MAC key is verified.
  • the verification frame is an example of the MAC added to the data frame, and is not limited to this.
  • the MAC added to the data frame may be a method of adding the MAC to a normal data frame. For example, when only 4 bytes of the 8 bytes in the data field are used for data transmission, only the upper 4 bytes or the lower 4 bytes of the 16 bytes of the MAC value are added to the remaining 4 bytes of the data field Can be considered. It is also conceivable that only 1 byte of the 16 bytes of the MAC value is added to the remaining 4 bytes of the data field.
  • FIG. 6 is a diagram illustrating an example of a MAC transmission method in Ethernet (registered trademark) communication.
  • FIG. 6A shows a MAC frame (Media Access Control Frame) that is a cluster of information transmitted in Ethernet (registered trademark) communication.
  • the MAC frame (hereinafter also referred to as a frame) includes data obtained by dividing communication data to be transmitted in Ethernet (registered trademark) communication to a certain length or less, a header, a transmission source address, a transmission destination address, and the like. A set of information in a predetermined format.
  • FIG. 6B shows an example of a MAC frame used for MAC transmission.
  • the MAC frame is transmitted by including the MAC frame encrypted by using a key (referred to as a MAC key) with an encryption method such as AES as a message authentication code (that is, MAC) in the payload portion and transmitting the MAC frame.
  • a key referred to as a MAC key
  • AES an encryption method
  • the first electronic control unit which is one of the plurality of electronic control units, transmits the MAC frame by including the MAC in the payload portion as the MAC added to the MAC frame.
  • the first electronic control unit generates a MAC using a MAC key for a value obtained by combining at least the transmission source address and transmission destination address added to the MAC frame and the number of transmissions of the MAC frame counted by the transmission counter.
  • a second electronic control unit that is at least one of the plurality of electronic control units other than the first electronic control unit among the plurality of electronic control units receives the MAC frame transmitted by the first electronic control unit. Then, the second electronic control unit is counted by the MAC obtained by receiving the frame including the MAC in the payload portion, the transmission source address and the transmission destination address added to the received MAC frame, and the reception counter. The identity of the MAC generated using the MAC key is verified with respect to a value obtained by combining at least the number of receptions of the MAC frame.
  • a MAC may be generated using a MAC key for a value obtained by combining at least the number of transmissions of the data frame counted by the transmission counter.
  • FIG. 7 is a block diagram showing a functional configuration of the ECU 111 in the present embodiment.
  • the ECU 111 is an electronic control unit connected to an in-vehicle network mounted on a vehicle, and has a CPU (Central Processing Unit) and a memory. As shown in FIG. 7, the ECU 111 includes a frame transmission / reception unit 1111, a frame interpretation unit 1112, a reception ID determination unit 1113, a reception ID list holding unit 1114, a frame processing unit 1115, a vehicle body state holding unit 1116, Determination rule storage unit 1117, timer 1118, key update determination unit 1119, update processing unit 1120, MAC key storage unit 1121, counter storage unit 1122, MAC generation unit 1123, frame generation unit 1124, data An acquisition unit 1125.
  • a frame transmission / reception unit 1111 As shown in FIG. 7, the ECU 111 includes a frame transmission / reception unit 1111, a frame interpretation unit 1112, a reception ID determination unit 1113, a reception ID list holding unit 1114, a frame processing unit 1115, a vehicle body state holding unit 1116, Determination rule
  • the vehicle body state holding unit 1116, the determination rule holding unit 1117, the timer 1118, and the key update determination unit constitute a key update process determination unit 13a that is an example of the key update process determination unit 13.
  • the update processing unit 1120, the MAC key holding unit 1121, the counter holding unit 1122, and the MAC generation unit 1123 constitute a key update unit 12 a that is an example of the key update unit 12.
  • Each of these components is a functional component, and each function is realized by a communication circuit in the ECU 111, a processor that executes a control program stored in a memory, a digital circuit, or the like.
  • the ECUs 131 to 191 have the same configuration and function as the key update management device 10. In the following description, it is assumed that the in-vehicle network is a CAN.
  • the frame transmission / reception unit 1111 transmits / receives a frame according to the CAN protocol to / from the bus. Also, the frame transmission / reception unit 1111 receives a frame bit by bit from the bus and transfers it to the frame interpretation unit 1112. The frame transmission / reception unit 1111 transmits the contents of the frame notified from the frame generation unit 1124 to the bus.
  • the frame interpretation unit 1112 receives the value of the frame transferred and received by the frame transmission / reception unit 1111 and interprets it so as to map it to each field in the frame format defined by the CAN protocol.
  • the frame interpretation unit 1112 notifies the reception ID determination unit 1113 of the value interpreted as the ID field.
  • the frame interpretation unit 1112 transfers the value of the ID field and the value of the data field appearing after the ID field to the frame processing unit 1115 according to the determination result notified from the reception ID determination unit 1113, or The reception of the frame is stopped by stopping the interpretation after the determination result is notified.
  • the frame interpretation unit 1112 When the value of the data field appearing after the ID field is transferred to the frame processing unit 1115, the frame interpretation unit 1112 notifies the frame processing unit 1115 of the contents of the ACK slot in the data frame interpreted from the received frame value. To do.
  • the frame interpretation unit 1112 interprets the received frame value as a frame that does not conform to the CAN protocol, the frame interpretation unit 1112 notifies the frame generation unit 1124 of an instruction to transmit an error frame.
  • the frame interpretation unit 1112 interprets that the frame is an error frame from the value of the received frame, thereafter, the frame interpretation unit 1112 stops the interpretation of the frame and discards the frame.
  • the reception ID determination unit 1113 receives the value of the ID field notified from the frame interpretation unit 1112, and receives each field of the frame after the ID field according to the list of message IDs held in the reception ID list holding unit 1114. Judge whether to do. The reception ID determination unit 1113 notifies the frame interpretation unit 1112 of the determination result.
  • the reception ID list holding unit 1114 holds a reception ID list that is a list of IDs (message IDs) received by the ECU 111. An example of the reception ID list will be described with reference to FIG.
  • FIG. 8 is a diagram showing an example of the reception ID list in the present embodiment.
  • FIG. 8 shows an example of a message ID list received by the ECU 111, the ECU 131, the ECU 182, the ECU 184, and the ECU 186.
  • the message IDs “1”, “2”, “3”, and “4” are received. The settings are shown.
  • the frame processing unit 1115 verifies the MAC, which is a tampering prevention code added to all the data frames received from the frame interpretation unit 1112. This MAC verification has the significance of verifying the validity of the data frame (message).
  • the frame processing unit 1115 obtains the MAC key corresponding to the message ID of the received data frame from the MAC key holding unit 1121, and obtains the counter value corresponding to the message ID from the counter holding unit 1122.
  • the MAC included in the data field of the verification data frame received following the data frame is verified.
  • the frame processing unit 1115 combines at least the MAC obtained by receiving the verification data frame, the ID corresponding to the received data frame, and the number of times of reception of the data counted by the reception counter. On the other hand, the identity with the MAC generated using the MAC key is verified. In the present embodiment, the frame processing unit 1115 first generates a MAC by calculation using the same method (described later) as the MAC generating unit 1123, and then generates the generated MAC and the data of the verification data frame. The MAC included in the field is compared. Then, the frame processing unit 1115 determines that the verification is successful if both MACs match, and determines that the verification fails, that is, an error if the MACs do not match. If the frame processing unit 1115 determines that an error has occurred, the frame processing unit 1115 notifies the frame interpretation unit 1112 and stops the subsequent reception processing.
  • the frame processing unit 1115 verifies the MAC, even if an illegal frame transmitted by an unauthorized ECU connected to the bus is received, it can be determined as an error and the reception process can be stopped. It is possible to prevent the vehicle from being controlled by the above.
  • the frame processing unit 1115 receives a frame for notifying the vehicle state (hereinafter referred to as vehicle state) and / or travel information
  • vehicle state a frame for notifying the vehicle state
  • the frame state holding unit 1116 notifies the received vehicle state and / or travel information.
  • the vehicle state is, for example, “running”, “stopped”, or “parking”, and indicates whether the vehicle is running or can be moved.
  • the vehicle state is specified by the ECU 121 connected to the transmission 120 based on the gear positions such as parking, neutral, first speed, second speed, etc. obtained from the transmission 120, and is included in the frame and notified to the bus. Good.
  • the vehicle state may be, for example, an ECU (not shown in FIG. 3) that identifies the vehicle state based on information notified from a plurality of ECUs and includes the frame in a frame and notifies the bus.
  • the travel information is information related to the travel of the vehicle, for example, the position acquired by the GPS sensor 187 or the travel distance or travel time of the vehicle detected by another sensor, and the vehicle speed acquired by the ECU 111 from the engine 110 and It is the speed of the vehicle.
  • the frame processing unit 1115 has the function of the acquisition unit 11 described above, and acquires travel information that is information regarding the travel of the vehicle transmitted from at least one of the plurality of electronic control units.
  • the frame processing unit 1115 performs processing according to the received frame data. It is assumed that the ECU 111 has a function of sounding an alarm sound such as having a speaker for sounding an alarm sound to a vehicle occupant. For example, when receiving information indicating that the door is open in a situation where the speed of the vehicle obtained by traveling information or information obtained from the engine 110 exceeds 30 km, the frame processing unit 1115 An alarm sound may be sounded to the passenger. In this way, the frame processing unit 1115 manages a data frame received from another ECU, for example, notifying the state of the door, and performs a process of sounding an alarm sound under a certain condition based on the vehicle speed obtained from the engine 110. The process according to the received frame data is performed.
  • the frame processing unit 1115 has been described as being common to a plurality of ECUs, a different process may be performed for each ECU. For example, when the door is opened in a state where the brake is not applied, the ECU 184 performs a process of sounding an alarm sound to the vehicle occupant, while the ECU 131, the ECU 182 and the like do not perform a process of sounding the alarm sound. It is good. ECU 111 to ECU 186 may or may not have functions other than the function of sounding an alarm sound.
  • the frame processing unit 1115 confirms the value of the ACK slot in the data frame received from the frame interpretation unit 1112 and confirms whether the frame transmitted from the frame transmission / reception unit 1111 is normally received by another ECU. To do. Then, the frame processing unit 1115 notifies the update processing unit 1120 of the confirmed result.
  • the vehicle body state holding unit 1116 holds the current vehicle state and the current traveling state notified from the frame processing unit 1115. As a result, the vehicle body state holding unit 1116 holds the vehicle state and the travel information notified to date. Specifically, the vehicle body state holding unit 1116 holds, for example, “running”, “stopped”, and “parking” as the vehicle state as described above. Further, as described above, for example, GPS information indicating the travel distance, the vehicle speed, and the vehicle position is held as the travel information.
  • the vehicle body state holding unit 1116 notifies the key update determination unit 1119 when the travel distance obtained from the travel information and the travel distance of the vehicle since the previous update of the MAC key has exceeded the threshold value.
  • the travel distance obtained from the travel information may be a travel distance of the vehicle detected by another sensor, a travel distance calculated based on a position acquired by the GPS sensor 187, a vehicle speed acquired from the engine 110, and It may be a distance calculated from the time of the vehicle speed.
  • the determination rule holding unit 1117 holds a determination rule used by the key update determination unit 1119.
  • the determination rule is a rule for determining whether or not the update processing unit 1120 satisfies a condition for executing the update process.
  • an example of the determination rule will be described with reference to FIGS. 9A and 9B.
  • FIG. 9A and FIG. 9B are diagrams showing an example of the determination rule in the present embodiment.
  • FIG. 9A shows an example of the determination rule according to the vehicle state
  • FIG. 9B shows an example of the determination rule according to the travel information.
  • FIG. 9A shows a determination rule for not performing the update process when the vehicle state is “running” or “stopped”.
  • a determination rule for performing the update process is shown. That is, according to the determination rule shown in FIG. 9A, for example, when the vehicle state is “running” or “stopped”, the update processing unit 1120 executes the update process even when the update timing of the MAC key update comes. It is determined that the condition is not satisfied, and the update process is not performed.
  • the vehicle state changes to “parking” it is determined that the update processing unit 1120 satisfies the condition for executing the update process, and the update process is executed.
  • the vehicle state is “parked” and the update timing of the MAC key update arrives, it is determined that the update processing unit 1120 satisfies the condition for executing the update process.
  • FIG. 9B shows a determination rule in which the update process is not performed if the travel distance of the vehicle is equal to or less than the threshold value D1, and the update process is performed if it is above the threshold value D1. Further, a determination rule is shown in which the update process is not performed if the moving distance of the vehicle by GPS is equal to or less than the threshold value D2, and the update process is performed if it is above the threshold value D2.
  • the travel distance of the vehicle by GPS is obtained from the position acquired by the GPS sensor 187 included in the travel information. That is, the travel distance of the vehicle by GPS may be included in the travel distance of the vehicle obtained from the travel information.
  • the update processing unit 1120 determines that the update processing unit 1120 does not satisfy the condition for executing the update process, and the update process is not performed. . If the travel distance of the vehicle is above the threshold value D1 or the travel distance of the vehicle by GPS is above the threshold value D2, the update processing unit 1120 executes the update process even before the update timing of the MAC key update arrives. It is determined that the conditions to be satisfied are satisfied, and update processing is performed.
  • Whether or not the update processing unit 1120 satisfies the condition for executing the update process may be determined according to any one of the determination rules for the vehicle state and the travel information, or both the vehicle state and the travel information. It may be performed according to the determination rule.
  • the update processing unit 1120 performs the update process. It may be determined that the conditions for execution are not satisfied, and the update process may not be performed.
  • the update processing unit 1120 does not satisfy the condition for executing the update process. It is good.
  • the timer 1118 is a timing mechanism that repeatedly counts up the timer value corresponding to the elapsed time.
  • the timer 1118 notifies the key update determination unit 1119 of the elapsed time from the completion of the previous update process of the MAC key.
  • the timer 1118 resets the timer value based on the update processing completion notification from the key update determination unit 1119.
  • the key update determination unit 1119 determines whether or not the update processing unit 1120 satisfies a condition for executing the update processing.
  • the key update determination unit 1119 may determine whether the update timing of the MAC key update has arrived.
  • the update timing is a timing at which a predetermined time (for example, 6 hours, 1 day, etc.) has elapsed, and is determined based on the timer 1118.
  • the condition for the update processing unit 1120 to execute the update process is to satisfy that the state relating to the traveling of the vehicle obtained from the traveling information is a predetermined state.
  • the predetermined state is before the update timing of the MAC key update arrives, it is the vehicle travel distance obtained from the travel information and the vehicle travel distance from the last update of the MAC key exceeds the threshold It is.
  • the predetermined state is a state in which the state of the vehicle is parked after the update timing of the MAC key update has arrived.
  • the key update determination unit 1119 acquires the current vehicle state from the vehicle body state holding unit 1116 and acquires from the determination rule holding unit 1117 when a predetermined update timing arrives.
  • the update processing unit 1120 determines whether or not a condition for executing the update process is satisfied.
  • the update process includes at least a MAC key update process, and also includes an update process related to updating data used for generating a MAC. More specifically, in the update process, a key update process for updating a MAC key value that is a key used for generating a MAC, and a counter value reflected in the MAC are reset (that is, updated to a specific value such as zero). Means counter reset processing.
  • the key update determination unit 1119 when it is determined that the update processing unit 1120 satisfies the condition for executing the update processing, the key update determination unit 1119 notifies the update processing unit 1120 to that effect. On the other hand, when it is determined that the update processing unit 1120 does not satisfy the conditions for executing the update process, the key update determination unit 1119 waits for a change in the vehicle state.
  • the key update determination unit 1119 acquires travel information including the present from the vehicle body state holding unit 1116 even if the predetermined update timing has not arrived, and responds to the determination rule acquired from the determination rule storage unit 1117. Thus, the update processing unit 1120 determines whether or not a condition for executing the update process is satisfied. When the key update determination unit 1119 determines that the update processing unit 1120 satisfies the condition for executing the update processing, the key update determination unit 1119 notifies the update processing unit 1120 to that effect. On the other hand, when it is determined that the update processing unit 1120 does not satisfy the conditions for executing the update process, the key update determination unit 1119 may wait until a predetermined update timing arrives and make a determination based on the vehicle state. .
  • the key update determination unit 1119 notifies the timer 1118 of the completion notification of the update process in order to cause the timer 1118 to reset the timer value.
  • the update processing unit 1120 performs update processing according to the notification from the key update determination unit 1119. That is, the update processing unit 1120 performs an update process for updating the MAC key on condition that the state related to the traveling of the vehicle obtained from the traveling information is a predetermined state.
  • the update processing unit 1120 notifies the timing at which the condition for executing the key update processing of the predetermined state is satisfied, thereby updating the MAC key to all the plurality of ECUs including the own ECU 111 at the same timing. Processing may be performed. That is, the update processing unit 1120 may generate a new MAC key using the MAC key at the same timing when the plurality of ECUs satisfy the above conditions. Then, the update processing unit 1120 may reset the transmission counter and the reception counter at the same timing that satisfies the above conditions.
  • the key update unit 12 may generate a new MAC key using the MAC key when the above condition is satisfied. Then, the key update unit 12 distributes the new MAC key generated at the timing satisfying the above conditions to all the plurality of ECUs except the own ECU 111, thereby updating the MAC key to all the plurality of ECUs at the same timing.
  • the key update process to be performed may be performed.
  • the update processing unit 1120 may reset the transmission counter and the reception counter at the same timing that satisfies the above conditions.
  • the update processing unit 1120 receives a notification from the key update determination unit 1119 that the update processing unit 1120 has determined that the conditions for executing the update processing are satisfied, and newly adds a key to be a MAC key candidate. Generate and notify the MAC key holding unit 1121. Further, upon receiving the notification, the update processing unit 1120 notifies the counter holding unit 1122 to reset the counter value. When receiving the notification, the update processing unit 1120 acquires the MAC key held by the MAC key holding unit 1121 and caches it as an old key (that is, temporarily holds it in a storage medium) and holds the counter. The counter value held by the unit 1122 is acquired and cached.
  • the update processing unit 1120 notifies the MAC key holding unit 1121 of the MAC key that is the cached old key when the update of the MAC key is not successful in one of the plurality of ECUs, and resets the cache.
  • the previous counter value is notified to the counter holding unit 1122.
  • the update processing unit 1120 deletes the cached MAC key that is the old key and the counter value before resetting. Note that these deletions are not limited to deletion of values stored in a temporary storage device (not shown) as long as these values that are temporarily held can be handled as those that can no longer be used.
  • the update processing unit 1120 uses, as a MAC key generation method, a new result derived by, for example, inputting the current MAC key as an old key into a predetermined one-way function such as a hash function.
  • a method for determining a MAC key candidate may be used.
  • the MAC key holding unit 1121 is realized by a storage medium such as a memory, and holds one MAC key for each message ID. As described above, the retained MAC key is necessary when the MAC generation unit 1123 and the frame processing unit 1115 calculate the MAC. Further, the MAC key holding unit 1121 updates the MAC key by discarding the MAC key held so far and holding the notified new MAC key in accordance with the notification from the update processing unit 1120.
  • the counter holding unit 1122 is realized including a storage medium such as a memory, and holds one counter value for each message ID.
  • the counter holding unit 1122 holds the notified counter value according to the notification from the update processing unit 1120, and resets the held counter value according to the notification from the update processing unit 1120 that it should be reset. By this reset, the counter value is updated to a specific value such as zero.
  • the counter value is required when the MAC generation unit 1123 and the frame processing unit 1115 calculate the MAC.
  • the counter value is incremented (increased by 1) when the frame is normally transmitted from the frame transmission / reception unit 1111.
  • the counter value is treated as a transmission counter when a data frame is transmitted from the frame transmission / reception unit 1111 and the number of transmissions is counted.
  • the counter value is handled as a reception counter when the frame transmission / reception unit 1111 receives a data frame, and the number of receptions is counted.
  • the counter holding unit 1122 treats the counter value corresponding to the message ID “1” among the held counter values as a transmission counter, and is normal Increments every time it is transmitted.
  • the counter holding unit 1122 uses a counter value corresponding to the message ID “1” among the held counter values as a reception counter. Handles and increments every time it is successfully received.
  • the MAC generation unit 1123 generates a MAC using a MAC key for a value obtained by combining at least an ID for identifying a data frame and the number of transmissions of the data frame counted by the transmission counter.
  • the MAC generation unit 1123 receives the message ID and data field data value notified from the frame generation unit 1124 and the counter value held by the counter holding unit 1122 (that is, the counter value corresponding to the message ID). ) Are combined (combined value). Then, the MAC generation unit 1123 uses the MAC key held by the MAC key holding unit 1121 (that is, the MAC key corresponding to the message ID) for the calculated combined value to calculate the MAC (that is, calculate the MAC value by calculation). ) To notify the frame generation unit 1124 of the calculated MAC.
  • HMAC Hash-based Message Authentication Code
  • Non-Patent Document 1 may be adopted as a MAC calculation method.
  • the MAC generation unit 1123 calculates the calculated combined value using a MAC key with a value padded up to a predetermined block of 4 bytes, for example, and uses the first 4 bytes of the calculated result as the MAC value. do it.
  • the MAC is generated by reflecting a counter value that is incremented every time a frame is transmitted. That is, even if the ECU 111 transmits a data frame including the same data value a plurality of times, the MAC assigned (that is, added) to the data frame changes every transmission.
  • a MAC may be generated using a MAC key for a value obtained by combining at least the transmission source address and transmission destination address added to the frame and the number of transmissions of the MAC frame counted by the transmission counter.
  • the frame generation unit 1124 configures an error frame and notifies the frame transmission / reception unit 1111 of the error frame according to the notification instructing transmission of the error frame notified from the frame interpretation unit 1112.
  • the frame generation unit 1124 notifies the MAC generation unit 1123 of the MAC by notifying the MAC generation unit 1123 of the predetermined message ID and the data value (data value for the data field) notified from the data acquisition unit 1125. receive.
  • the frame generation unit 1124 configures a frame based on the predetermined message ID, the notified MAC, and the notified data field data value, and notifies the frame transmission / reception unit 1111 of the frame.
  • the data acquisition unit 1125 acquires data indicating the state of devices, sensors, and the like connected to the ECU, and notifies the frame generation unit 1124 of the data.
  • FIG. 10 is a diagram showing an example of message ID and data transmitted by the ECU 111 connected to the engine 110 in the present embodiment.
  • the message ID transmitted by the ECU 111 is “1”, for example.
  • the first 1 byte represents the speed
  • the next 1 byte represents the counter
  • the next 4 bytes represent the MAC value.
  • Speed per hour ranges from a minimum of 0 km to a maximum of 180 km. That is, the ECU 111 transmits the first 1 byte value representing the speed per hour, the counter value and the MAC value corresponding to each value as a set in 6 bytes.
  • FIG. 10 shows that the vehicle is accelerated from 0 km to 1 km.
  • FIG. 11 is a diagram showing an example of message ID and data transmitted by ECU 131 connected to brake 130 in the present embodiment.
  • the message ID transmitted by the ECU 131 is “2”, for example.
  • the first 1 byte represents the degree of braking in%
  • the next 1 byte represents a counter
  • the next 4 bytes represent a MAC value.
  • the state where the brake is not applied at all is 0%
  • the state where the brake is applied to the maximum is 100%. That is, the ECU 131 transmits the first 1 byte value indicating the degree of brake application, the counter value corresponding to each value, and the MAC value in 6 bytes as a set.
  • FIG. 11 shows how the vehicle gradually weakens the brake from 100%.
  • FIG. 12 is a diagram illustrating an example of message ID and data transmitted by the ECU 184 connected to the door opening / closing sensor 185 according to the present embodiment.
  • the message ID transmitted by the ECU 184 is “3”, for example.
  • the first byte represents the door open / closed state
  • the next 1 byte represents the counter
  • the next 4 bytes represent the MAC value.
  • the state where the door is open is “1”, and the state where the door is closed is “0”.
  • the ECU 184 transmits the first 1 byte value indicating the open / closed state of the door, the counter value corresponding to each value, and the MAC value as a set in 6 bytes.
  • FIG. 12 shows a state in which the door is closed halfway from the open state.
  • FIG. 13 is a diagram showing an example of message ID and data transmitted by the ECU 182 connected to the window opening / closing sensor 183 in the present embodiment.
  • the message ID transmitted by the ECU 182 is “4”, for example.
  • the first 1 byte represents the open / closed state of the window in%
  • the next 1 byte represents the counter
  • the next 4 bytes represent the MAC value.
  • the state where the window is closed is 0%
  • the state where the window is fully open is 100%.
  • the ECU 182 transmits a 6-byte set of a leading 1-byte value indicating the open / closed state of the window, a counter value corresponding to each value, and a MAC value.
  • FIG. 13 shows a state where the window is gradually opened from the closed state.
  • FIG. 14 is a diagram illustrating an example of message ID and data transmitted by the ECU 186 connected to the GPS sensor 187 in the embodiment.
  • the message ID transmitted by the ECU 182 is “5”, for example.
  • the first 3 bytes represent the GPS difference
  • the next 1 byte represents the counter
  • the next 4 bytes represent the MAC value. That is, ECU 186 transmits the difference value from the previous position, the counter value, and the MAC value as a set in 8 bytes.
  • FIG. 15 is a flowchart showing the update processing method in the present embodiment.
  • the key update management device 10 configuring the in-vehicle network system 100 will be described as performing update processing, but the present invention is not limited to this.
  • Each ECU may perform the update process, one of all ECUs may perform the update process as the key update management device 10, or the gateway 101 constituting the in-vehicle network system 100a may perform the update process.
  • the key update management device 10 acquires travel information, which is information related to the travel of the vehicle, transmitted from at least one of the plurality of electronic control units (S10).
  • the key update management device 10 determines whether or not a condition that the state relating to the traveling of the vehicle obtained from the traveling information is a predetermined state is satisfied (S11).
  • step S11 if the above condition is satisfied (Y in S11), the key update management device 10 is a MAC (message authentication code) added to data exchanged in the in-vehicle network system 100 and is a code for preventing falsification.
  • the MAC key that is a key used for generating a certain MAC is updated (S12).
  • step S11 if the above condition is not satisfied (N in S11), the process returns to step S10.
  • FIG. 16 is a flowchart showing detailed processing of step S11 shown in FIG. Below, the case where ECU111 which is one of several ECUs which comprise in-vehicle network system 100a performs update processing as key update management device 10 is mentioned as an example, and is explained.
  • step S11 the ECU 111 confirms the elapsed time from the completion of the previous update process by the internal timer 1118 (S1101).
  • the ECU 111 determines whether or not a predetermined time has elapsed since the completion of the previous update process (S1102). More specifically, the ECU 111 determines whether the update timing for MAC key update has arrived based on the elapsed time counted by the timer 1118.
  • step S1102 if the predetermined time has not elapsed since the completion of the previous update process (N in S1102), the ECU 111 checks the distance traveled by the vehicle since the completion of the previous update process (S1103). More specifically, the ECU 111 checks the vehicle travel distance obtained from the travel information and the vehicle travel distance from the last update of the MAC key.
  • the ECU 111 determines whether the distance traveled by the vehicle since the completion of the previous update process is greater than a predetermined threshold (S1104). For example, according to the determination rule as shown in FIG. 9B, the ECU 111 determines whether the distance the vehicle has traveled since the completion of the previous update process is greater than the threshold.
  • step S1104 the ECU 111 returns to S1101 when the distance the vehicle has traveled since the completion of the previous update process is less than or equal to the threshold (N in S1104).
  • step S1104 if the distance the vehicle has traveled since the completion of the previous update process is greater than the threshold (Y in S1104), the ECU 111 ends the process of step S11 and proceeds to step S12 shown in FIG. In step S1104, when the distance the vehicle has traveled since the completion of the previous update process is equal to or smaller than the threshold (N in S1104), ECU 111 returns to step S10 shown in FIG.
  • step S1102 if a predetermined time has elapsed since the completion of the previous update process (Y in S1102), the ECU 111 confirms the current vehicle state (S1105) and determines whether the vehicle is parked. Is determined (S1106).
  • step S1106 If the vehicle is parked (Y in S1106), the ECU 111 ends the process of step S11 and proceeds to step S12 shown in FIG. On the other hand, if the vehicle is parked (N in S1106), ECU 111 returns to step S1105.
  • step S1104 the ECU 111 ends the process of step S11 when the distance the vehicle has traveled since the completion of the previous update process is greater than the threshold (Y in S1104), but is not limited thereto. Furthermore, the processing in steps S1105 and S1106 may be performed.
  • the ECU 111 determines whether the determination rule held in the determination rule holding unit 1117 is the vehicle travel distance obtained from the current vehicle state or travel information, and the travel distance of the vehicle since the last update of the MAC key. It can be determined whether or not to execute the update process according to the rule.
  • the ECU 111 when following the determination rule shown in FIG. 9A, the ECU 111 does not execute the update process if the vehicle state is “running” or “stopped”. On the other hand, if the vehicle state is “parked”, update processing is executed. Further, in the case of following the determination rule shown in FIG. 9B, the ECU 111 updates the update process if the vehicle travel distance obtained from the travel information and the travel distance of the vehicle since the last update of the MAC key is equal to or less than the threshold value D1. Do not execute. If the travel distance indicated by the GPS travel distance is equal to or less than the threshold D2, the update process is not executed.
  • FIG. 17 is an example of a flowchart showing the detailed process of step S12 shown in FIG.
  • the ECU 111 that is one of a plurality of ECUs configuring the in-vehicle network system 100a executes the update process
  • a new MAC key generated at a timing that satisfies the condition for executing the key update process is distributed to all of the plurality of ECUs other than the own ECU 111, whereby the MAC key is assigned to all of the plurality of ECUs.
  • An update process for updating at the same timing is shown.
  • step S12 the ECU 111 caches the MAC key held by the MAC key holding unit 1121 as an old key (S1201). Subsequently, the ECU 111 sets the generated key as a MAC key (S1202). More specifically, the ECU 111 newly generates a key that becomes a MAC key candidate and holds it in the MAC key holding unit 1121 as a MAC key.
  • the ECU 111 caches the counter value held by the counter holding unit 1122 (S1203). Subsequently, the ECU 111 resets the counter value held by the counter holding unit 1122 to zero (S1204).
  • the ECU 111 generates a MAC using the generated MAC key (S1205). More specifically, the ECU 111 stores a predetermined message ID, a data value for the data field, a counter value held by the counter holding unit 1122 after reset, and a MAC key holding unit 1121 The MAC is generated using the newly generated MAC key.
  • the ECU 111 generates and broadcasts a key distribution frame that is a data frame for distributing the generated MAC key, and then broadcasts an update frame that is a data frame for confirming the synchronization of the update (S1206). ). More specifically, first, the ECU 111 generates a key distribution frame including the message ID, the data value for the data field, and the MAC key generated in step S1202 and transmits the generated key distribution frame to the bus. The MAC key is updated at the same timing in all ECUs. Subsequently, the ECU 111 generates an update frame including the message ID, the data value for the data field, and the MAC generated in step S1205, and transmits it to the bus. Other ECUs that have received the key distribution frame cache the MAC key, which is the old key, and the counter value before reset, like ECU 111.
  • the ECU 111 determines whether or not all of the plurality of ECUs excluding the ECU 111 have successfully received the update frame (S1207). More specifically, after sending the update frame to the bus in step S1206, the ECU 111 determines whether all of the plurality of ECUs other than the ECU 111 have successfully received the update frame (that is, received normally). Judge by seeing.
  • step S1207 If it is determined in step S1207 that all of the ECUs other than the ECU 111 have successfully received the updated frame (Y in S1207), the ECU 111 determines that the MAC key that is the cached old key, the counter value before resetting, Is discarded (S1208), and the update process is terminated. This is because, when all of the plurality of ECUs other than the own ECU 111 have successfully received the update frame, it is understood that the update of the MAC key is completed with the new MAC key in all of the plurality of ECUs.
  • the ECU 111 sets the MAC key that is the cached old key as the MAC key again (S1210) and caches it.
  • the counter value before reset is set again (S1211). More specifically, when there is an ECU that failed to receive the update frame, the ECU 111 causes the MAC key holding unit 1121 to hold the MAC key that is the cached old key. Further, the ECU 111 causes the counter holding unit 1122 to hold the cached counter value before resetting as the counter value again. Other ECUs, like ECU 111, set the cached MAC key, which is the old key, as the MAC key again, and reset the cached counter value before resetting. Even if there is an ECU that did not successfully receive the update frame, it is determined whether there was an ECU that failed to receive the update frame after broadcasting the key distribution frame again and distributing a new MAC key again. May be.
  • the ECU 111 generates a MAC using the reset MAC key and counter value (S1212). More specifically, the ECU 111 determines a predetermined message ID, a data value for the data field, a counter value of the counter holding unit 1122 reset from the cache, and a MAC key holding unit 1121 reset from the cache. A MAC is generated using the MAC key.
  • the ECU 111 broadcasts an update frame that is a data frame for confirming the synchronization of the update (S1213). More specifically, the ECU 111 generates an update frame including the message ID, the data value for the data field, and the MAC generated in step S1212 and transmits it to the bus.
  • the ECU 111 determines whether or not all the plurality of ECUs excluding the self ECU 111 have successfully received the update frame (S1214). More specifically, after transmitting the update frame to the bus in step S1213, the ECU 111 determines whether or not all of the ECUs other than the ECU 111 have successfully received the update frame by looking at the value of the ACK slot. .
  • Step S1214 when it is determined that all of the plurality of ECUs other than the own ECU 111 have successfully received the update frame (Y in S1214), the ECU 111 performs the update process again after waiting for a certain time (S1215). That is, the ECU 111 returns to step S1201 and performs the update process again, assuming that the update of the MAC key failed was a minor error.
  • step S1214 if it is determined in step S1214 that reception of the update frame has failed (N in S1214), the ECU 111 stops processing for occurrence of a fatal error (S1216).
  • the ECU 111 fails to receive the update frame transmitted to confirm that it has been returned to the old key because the update of the MAC key has failed, because it can be regarded as a fatal error in the system.
  • the ECU 111 may execute processes such as notification of error occurrence and log recording. Further, the notification of the occurrence of an error can be executed by transmitting a data frame indicating the occurrence of an error to another ECU, displaying on a display or the like, outputting sound, emitting light, or the like.
  • FIG. 18 is another example of a flowchart showing the detailed processing of step S12 shown in FIG. 18 also illustrates an example in which the ECU 111, which is one of a plurality of ECUs constituting the in-vehicle network system 100a, executes the update process, as in FIG. Elements similar to those in FIG. 17 are denoted by the same reference numerals, and detailed description thereof is omitted.
  • the ECU 111 broadcasts a notification frame indicating the timing of key update. More specifically, the ECU 111 transmits a notification frame indicating the key update timing to the bus in order to notify the timing when the condition for executing the key update processing in the predetermined state is satisfied.
  • the notification frame indicating the key update timing the current MAC key, which is an old key, may be included in the data field and sent, or the fact indicating the key update timing may be included in the data field and transmitted.
  • the MAC key can be updated at the same timing by all of the plurality of ECUs including the own ECU 111. As described above, it is not essential to notify the timing when the condition for executing the key update process is satisfied. If it is CAN, even if it determines the timing when all the ECUs satisfy the conditions for executing the key update process independently, the same timing can be determined, so that all the ECUs can be updated at the same timing. Because it can.
  • the ECU 111 performs steps S1201 to S1205.
  • the other ECUs that have received the notification frame indicating the key update timing cache the MAC key, which is the old key, and the counter value before the reset, like the ECU 111.
  • the ECU 111 broadcasts an update frame that is a data frame for confirming the synchronization of the update. More specifically, the ECU 111 generates an update frame including the message ID, the data value for the data field, and the MAC generated in step S1205 and transmits it to the bus.
  • step S1207A the ECU 111 determines whether or not all the plurality of ECUs excluding the own ECU 111 have successfully received the update frame.
  • step S1207A when it is determined that all of the plurality of ECUs other than the own ECU 111 have successfully received the updated frame (Y in S1207A), the ECU 111 determines that the cached MAC key is the old key and the counter value before resetting. Is discarded (S1208), and the update process is terminated.
  • step S1207A the ECU 111 sets the MAC key, which is the cached old key, as the MAC key again and caches it.
  • the counter value before reset is set again (S1218).
  • the plurality of ECUs can determine whether or not the update frame has been successfully received by looking at the value of the ACK slot, the plurality of ECUs performs the process of step S1218 as in the case of the ECU 111.
  • the ECU 111 performs update processing again (S1219). That is, the ECU 111 returns to step S1217 and performs the update process again because it is a minor error that the update of the MAC key has failed.
  • any ECU may transmit the update frame.
  • the ECU 111 that repeatedly transmits the data frame of the message ID “1” is described as transmitting an update frame for synchronizing the update processing related to the MAC corresponding to the message ID “1”.
  • the update process including the key update process of the MAC key and the reset process of the counter can be executed according to the travel distance and / or the vehicle state.
  • an update process can be performed with a suitable frequency according to operation
  • the update process is performed when the travel distance is short and the vehicle is operating or is scheduled.
  • the update process can be executed according to the travel distance and / or the state of the vehicle.
  • the frame is periodically transmitted, but may be transmitted as an event for notifying the state change.
  • the frame may be transmitted only when the door lock state changes. Further, it may be transmitted periodically and when a state change occurs.
  • the size of the MAC included in the frame is not limited to 4 bytes, and may be different for each transmission.
  • the counter size is not limited to 1 byte.
  • the frame it is not necessary for the frame to include all of the data value, counter value, MAC value, and other field values included in the data frame, and any combination thereof may be used.
  • the MAC size is not limited to a fixed size, and may be a different size for each message ID. Further, it may be transmitted across a plurality of messages.
  • the counter value is incremented every transmission, but may be a value that is automatically incremented according to time. Further, the value of the time itself may be used instead of the counter.
  • the data frame in the CAN protocol is described in the standard ID format, but it may be in the extended ID format.
  • the MAC calculation algorithm is HMAC, but the present invention is not limited to this. CBC-MAC and CMAC may be used.
  • the padding that appears in the MAC calculation may be zero padding, ISO10126, PKCS1, PKCS5, PKCS7, or any other padding method that requires a data size for the calculation.
  • either the head, the tail or the middle may be taken. Moreover, even if it is not 4 bytes continuous, you may collect and combine 1 bit at a time according to a specific rule.
  • the MAC key update process and the counter reset process are simultaneously performed, but only one of them may be performed. Also for the MAC key update process, a new key dedicated to the MAC key update process may be embedded.
  • one MAC key is held for each message ID, but one MAC key may be used for each ECU. Moreover, all ECUs may hold a common MAC key. All ECUs connected to the same bus may hold a common MAC key.
  • one counter value is held for each message ID, but one counter value may be used for each ECU. Also, a common counter value may be used for all frames flowing on the same bus.
  • the counter value is used for MAC calculation, but may be included in the data field for transmission. In that case, all the counter values may be transmitted, or only a part may be transmitted.
  • the determination rule is not limited to an example, and may be another determination rule or a plurality of determination rules. Further, the determination rule may be set in the ECU at the time of shipment, may be set at the time of shipment of the mounted vehicle body, or may be set as a part or when the mounted vehicle body itself is sold. Good. The determination rule may be set by communication with the outside, various media, or various diagnostic tools.
  • the received ECU performs MAC verification on data frames transmitted and received between ECUs.
  • MAC verification that performs verification of the MAC assigned to all data frames at once. ECU may be used.
  • the MAC verification ECU may hold MAC keys and counter values corresponding to all message IDs. Further, when the MAC verification ECU determines an error as a result of the MAC verification, an error frame may be transmitted in order to prevent reception by other ECUs.
  • the key update process is performed for all the MAC keys.
  • the present invention is not limited to this, but only the MAC key of the message ID related to the travel distance. May be updated.
  • the key update process is performed for all the MAC keys.
  • the present invention is not limited to this, and a message ID related to the travel distance is transmitted.
  • the bus-only MAC key may be updated.
  • the update process is performed based on the determination rule when a predetermined time has elapsed or the travel distance is greater than the threshold.
  • the present invention is not limited to this, and the counter value is the threshold. If it is larger, the update process may be executed. At this time, only the MAC key corresponding to the message ID whose counter value is larger than the threshold value may be updated.
  • Each device in the above embodiment is specifically a computer system including a microprocessor, a ROM, a RAM, a hard disk unit, a display unit, a keyboard, a mouse, and the like.
  • a computer program is recorded in the RAM or hard disk unit.
  • Each device achieves its functions by the microprocessor operating according to the computer program.
  • the computer program is configured by combining a plurality of instruction codes indicating instructions for the computer in order to achieve a predetermined function.
  • part or all of the constituent elements may be configured by a single system LSI (Large Scale Integration).
  • the system LSI is an ultra-multifunctional LSI manufactured by integrating a plurality of components on a single chip, and specifically, a computer system including a microprocessor, ROM, RAM, and the like. . A computer program is recorded in the RAM.
  • the system LSI achieves its functions by the microprocessor operating according to the computer program.
  • each part of the constituent elements constituting each of the above devices may be individually made into one chip, or may be made into one chip so as to include a part or all of them.
  • the system LSI is used here, it may be called IC, LSI, super LSI, or ultra LSI depending on the degree of integration. Further, the method of circuit integration is not limited to LSI's, and implementation using dedicated circuitry or general purpose processors is also possible.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable processor that can reconfigure the connection or setting of circuit cells inside the LSI may be used.
  • a part or all of the constituent elements constituting each of the above-described devices may be configured by an IC card or a single module that is removable from each device.
  • the IC card or module is a computer system that includes a microprocessor, ROM, RAM, and the like.
  • the IC card or the module may include the super multifunctional LSI described above.
  • the IC card or the module achieves its functions by the microprocessor operating according to the computer program. This IC card or this module may have tamper resistance.
  • the present disclosure may be the method described above. Further, the present invention may be a computer program that realizes these methods by a computer, or may be a digital signal composed of a computer program.
  • the present disclosure also discloses a computer program or a recording medium that can read a digital signal, such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray (registered) (Trademark) (Disc), recorded in a semiconductor memory or the like.
  • a digital signal such as a flexible disk, hard disk, CD-ROM, MO, DVD, DVD-ROM, DVD-RAM, BD (Blu-ray (registered) (Trademark) (Disc), recorded in a semiconductor memory or the like.
  • the digital signal may be recorded on these recording media.
  • the present disclosure may transmit a computer program or a digital signal via an electric communication line, a wireless or wired communication line, a network represented by the Internet, data broadcasting, or the like.
  • the present disclosure may be a computer system including a microprocessor and a memory.
  • the memory may record the computer program, and the microprocessor may operate according to the computer program.
  • program or digital signal may be recorded on a recording medium and transferred, or the program or digital signal may be transferred via a network or the like, and may be implemented by another independent computer system.
  • the update process of the MAC key in the ECU is reliably performed without concentrating on a specific timing, and the entire in-vehicle network system can be maintained in a safe state.
  • SYMBOLS 10 Key update management apparatus 11 Acquisition part 12,12a Key update part 13,13a Key update process determination part 100,100a In-vehicle network system 101 Gateway 111,121,131,141,151,161,171,181,182,184 186,191 ECU DESCRIPTION OF SYMBOLS 110 Engine 120 Transmission 130 Brake 140 Steering 150 Automatic brake 160 Lane keeping device 170 Inter-vehicle communication device 180 Head unit 183 Window opening / closing sensor 185 Door opening / closing sensor 187 GPS sensor 190 ITS device 1111 Frame transmission / reception unit 1112 Frame interpretation unit 1113 Reception ID judgment unit 1114 Reception ID List Holding Unit 1115 Frame Processing Unit 1116 Body State Holding Unit 1117 Determination Rule Holding Unit 1118 Timer 1119 Key Update Determination Unit 1120 Update Processing Unit 1121 MAC Key Holding Unit 1122 Counter Holding Unit 1123 MAC Generation Unit 1124 Frame Generation Unit 1125 Data Acquisition department

Landscapes

  • Small-Scale Networks (AREA)

Abstract

複数の電子制御ユニットを有し、車両に搭載される車載ネットワークシステムにおいて用いられる鍵の更新処理方法であって、複数の電子制御ユニットの少なくとも一つから送信される、車両の走行に関する情報である走行情報を取得する取得ステップと、走行情報により得られる車両の走行に関する状態が所定状態であることを条件として、車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コードであって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵（ＭＡＣ：Message Authentication Code）を更新する鍵更新ステップとを含む。

Description

更新処理方法、車載ネットワークシステムおよび電子制御ユニット
　本開示は、更新処理方法、車載ネットワークシステムおよび電子制御ユニットに関する。
　近年、自動車の中のシステムには、電子制御ユニット（以下、ＥＣＵ：Engine Control Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークを車載ネットワークと呼ぶ。車載ネットワークには、多数の規格が存在する。その中でも最も主流な車載ネットワークの規格の一つに、Controller Area Network（以下、ＣＡＮ）という規格がある。
　ＣＡＮでは、通信線として用いられるバス（bus）は２本のケーブル（ツイストペア・ケーブル）で構成され、このバスに接続されているＥＣＵはノードと呼ばれる。バスに接続されている各ノードは、フレームと呼ばれるメッセージを送受信する。フレームを送信するノード（以下、送信ノードともいう）は２本のケーブルに電圧をかけ、それぞれのケーブル間で発生させた電位差の有無に応じたレセシブと呼ばれる“１”の値とドミナントと呼ばれる“０”の値とを送信することで、フレームのデータを２進数に変換したバイナリデータで送信する。
　なお、複数の送信ノードが全く同一のタイミングで、レセシブとドミナントとを送信した場合は、ドミナントが優先されて送信される。フレームを受信するノード（以下、受信ノードともいう）は、受け取ったフレームのフォーマットに異常がある場合には、例えば連続する６ｂｉｔのドミナントで始まるエラーフレームと呼ばれるフレームを送信する。受信ノードは、エラーフレームを送信することで、送信ノードおよび他の受信ノードにフレームの異常を通知することができる。
　また、ＣＡＮでは、送信先または送信元を指す識別子は存在しない。送信ノードはフレーム毎にメッセージＩＤと呼ばれるＩＤを付けて送信し、各受信ノードは予め決められたメッセージＩＤを含むフレームのみ受信する。
　また、ＣＡＮでは、ＣＳＭＡ／ＣＲ（Carrier Sense Multiple Access/Collision Resolution）方式が採用されており、複数ノードの同時送信時にはメッセージＩＤによる調停が行われ、メッセージＩＤの値が小さいフレームが優先的に送信される。
　一方、ＣＡＮでは、不正なフレームが送信されるようなケースを想定したセキュリティ機能が存在しない。そのため、不正なノードが勝手にＣＡＮのバスに接続し、不正なフレームを送信することで、当該ＣＡＮが搭載された自動車の車体を不正にコントロールすることが可能である。
　それに対して、例えば特許文献１では、ＣＡＮ通信に用いられるデータフレームおけるデータフィールドにメッセージ認証コードを埋め込んで送信する方法が開示されている。メッセージ認証コードは、ＭＡＣ（Message Authentication Code）ともいう。そして、通常のデータフレームに続けて、当該データフレームおけるデータフィールドにＭＡＣを埋め込んだデータフレームを送信することで、不正なフレームの送信を防止することができる。
特開２０１３－９８７１９号公報
RFC2104 HMAC:　Keyed-Hashing for Message Authentication
　本開示の一態様に係る更新処理方法は、複数の電子制御ユニットを有し、車両に搭載される車載ネットワークシステムにおいて用いられる鍵の更新処理方法であって、前記複数の電子制御ユニットの少なくとも一つから送信される、前記車両の走行に関する情報である走行情報を取得する取得ステップと、前記走行情報により得られる前記車両の走行に関する状態が所定状態であることを条件として、前記車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コードであって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵（ＭＡＣ：Message Authentication Code）を更新する鍵更新ステップとを含む。
　本開示の更新処理方法等は、車載ネットワークシステムにおいて用いられる鍵の更新を効率よく確実に実施することができる。これにより、安全な状態の車載ネットワークシステムを維持することができる。
図１は、実施の形態における車載ネットワークシステムの構成を示すブロック図である。 図２は、図１に示す鍵更新管理装置の構成の一例を示すブロック図である。 図３は、実施の形態における車載ネットワークシステムの全体構成の一例を示す図である。 図４は、ＣＡＮプロトコルのデータフレームのフォーマットを示す図である。 図５は、ＣＡＮ通信におけるＭＡＣの送信方法の一例を示す図である。 図６は、イーサネット（登録商標）通信におけるＭＡＣの送信方法の一例を示す図である。 図７は、実施の形態におけるＥＣＵの機能構成を示すブロック図である。 図８は、実施の形態における受信ＩＤリストの一例を示す図である。 図９Ａは、実施の形態における判定ルールの一例を示す図である。 図９Ｂは、実施の形態における判定ルールの一例を示す図である。 図１０は、実施の形態におけるエンジンに接続されたＥＣＵが送信するメッセージＩＤとデータの一例を示す図である。 図１１は、実施の形態におけるブレーキに接続されたＥＣＵが送信するメッセージＩＤとデータの一例を示す図である。 図１２は、実施の形態におけるドア開閉センサに接続されたＥＣＵが送信するメッセージＩＤとデータの一例を示す図である。 図１３は、実施の形態におけるウィンドウ開閉センサに接続されたＥＣＵが送信するメッセージＩＤとデータの一例を示す図である。 図１４は、実施の形態におけるＧＰＳセンサに接続されたＥＣＵが送信するメッセージＩＤとデータの一例を示す図である。 図１５は、実施の形態における更新処理方法を示すフローチャートである。 図１６は、図１５に示すステップＳ１１の詳細処理を示すフローチャートである。 図１７は、図１５に示すステップＳ１２の詳細処理を示すフローチャートの一例である。 図１８は、図１５に示すステップＳ１２の詳細処理を示すフローチャートの別の一例である。
　ところで、ＣＡＮ通信に用いられるフレームには、ＭＡＣを付加するためのフィールドは存在しない。さらにＣＡＮ通信に用いられるデータフレームにおけるデータフィールドは８バイトと少なく、データフィールドに埋め込まれるＭＡＣのサイズでは、十分な攻撃の耐性を確保することが難しい。
　そこで、データフィールドに埋め込まれるＭＡＣに対する総当り攻撃の耐性を高めるために、ＭＡＣの生成に利用される鍵（以下、ＭＡＣ鍵ともいう）を定期的に更新することが望ましいと考えられる。
　しかしながら、定期的に鍵の更新を行うとすると、自動車の動作にかかわらず鍵を更新することになる。つまり、定期的に鍵の更新を行う場合、ＣＡＮにおいてフレームがほとんど送受信されていなくても鍵が更新されることから、車載ネットワークシステムにとって鍵の更新処理が負荷になることがある。
　本開示は、上述の事情を鑑みてなされたもので、車載ネットワークシステムにおいて用いられる鍵の更新を効率よく確実に実施することができる更新処理方法等を提供する。
　本開示の一態様の更新処理方法は、複数の電子制御ユニットを有し、車両に搭載される車載ネットワークシステムにおいて用いられる鍵の更新処理方法であって、前記複数の電子制御ユニットの少なくとも一つから送信される、前記車両の走行に関する情報である走行情報を取得する取得ステップと、前記走行情報により得られる前記車両の走行に関する状態が所定状態であることを条件として、前記車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コードであって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵（ＭＡＣ：Message Authentication Code）を更新する鍵更新ステップとを含む。
　これにより、ＭＡＣ鍵の鍵更新処理、および、カウンタのリセット処理を含む更新処理を、走行距離および／または車の状態に応じて実行することで、更新処理を車の動作に応じて、適切な頻度で実行できる。つまり、ＥＣＵにおける鍵の更新処理が効率よく適切に実行できる。それにより、車載ネットワークシステム全体として、安全な状態を維持することができる。
　また、前記所定状態は、前記走行情報により得られる前記車両の走行距離であって前記ＭＡＣ鍵の前回の更新時からの前記車両の走行距離が閾値を超えた状態であってもよい。
　また、前記所定状態は、前記ＭＡＣ鍵の前回の更新時から所定時間経過後、かつ、前記走行情報により得られる前記車両の状態が駐車中である状態であってもよい。
　また、前記鍵更新ステップでは、前記複数の電子制御ユニットのすべてが、前記条件を満たした同一のタイミングで、前記ＭＡＣ鍵を用いて新たなＭＡＣ鍵を生成することにより、前記ＭＡＣ鍵を前記新たなＭＡＣ鍵に更新してもよい。
　また、前記鍵更新ステップでは、前記複数の電子制御ユニットの一が、前記条件を満たしたときに、前記ＭＡＣ鍵を用いて新たなＭＡＣ鍵を生成する生成ステップと、前記一の電子制御ユニットが生成した前記新たなＭＡＣ鍵を、前記一の電子制御ユニット以外の前記複数の電子制御ユニットのすべてに配布することにより、前記ＭＡＣ鍵を前記新たなＭＡＣ鍵に更新する配布ステップとを含んでもよい。
　また、前記車載ネットワークは、前記複数の電子制御ユニットがバスに接続されたＣＡＮ（Controller Area Network）であり、前記更新処理方法は、前記複数の電子制御ユニットのうちの一である第１電子制御ユニットが、ＣＡＮプロトコルに従ってバスを介して、前記データとしてデータフレーム、および、前記データに付加されるメッセージ認証コードとして前記データフレームのデータフィールドを前記メッセージ認証コードとした検証用データフレームの送信を行う送信ステップと、前記複数の電子制御ユニットのうちの前記第１電子制御ユニット以外の複数の電子制御ユニットの少なくとも一である第２電子制御ユニットが、前記第１電子制御ユニットにより送信されたデータフレーム、および、検証用データフレームを、バスを介して受信する受信ステップとを含んでもよい。
　また、前記送信ステップでは、前記第１電子制御ユニットが、前記データフレームを識別するためのＩＤと送信カウンタによりカウントされたデータフレームの送信回数とを少なくとも結合した値に対して前記ＭＡＣ鍵を用いて前記メッセージ認証コードを生成するＭＡＣ生成ステップを含み、前記受信ステップでは、前記第２電子制御ユニットが、前記検証用データフレームを受信して得た前記メッセージ認証コードと、受信した前記データフレームに対応するＩＤと、受信カウンタによりカウントされたデータの受信回数とを少なくとも結合した値に対して、前記ＭＡＣ鍵を用いて生成したメッセージ認証コードとの同一性を検証する検証ステップを含んでもよい。
　また、前記車載ネットワークシステムは、前記複数の電子制御ユニットがＬＡＮ（Local Area Network）により接続されたネットワークであり、前記更新処理方法は、前記複数の電子制御ユニットのうちの一である第１電子制御ユニットが、前記データに付加される前記メッセージ認証コードとしてペイロード部分に前記メッセージ認証コードを含めて、前記データの送信を行う送信ステップと、前記複数の電子制御ユニットのうちの前記第１電子制御ユニット以外の複数の電子制御ユニットの少なくとも一である第２電子制御ユニットが、前記第１電子制御ユニットにより送信された前記データを受信する受信ステップとを含んでてもよい。
　また、前記送信ステップでは、さらに、前記第１電子制御ユニットが、前記データに付加された送信元アドレスおよび送信先アドレスと送信カウンタによりカウントされたデータの送信回数とを少なくとも結合した値に対して前記ＭＡＣ鍵を用いて前記メッセージ認証コードを生成するＭＡＣ生成ステップを含み、前記受信ステップでは、前記第２電子制御ユニットが、ペイロード部分に前記メッセージ認証コードが含まれた前記データを受信して得た前記メッセージ認証コードと、受信した当該データに付加された送信元アドレスおよぎ送信先アドレスと受信カウンタによりカウントされたデータの受信回数とを少なくとも結合した値に対して、前記ＭＡＣ鍵を用いて生成したメッセージ認証コードとの同一性を検証する検証ステップを含んでもよい。
　また、前記更新処理方法は、さらに、前記条件として前記送信カウンタおよび前記受信カウンタをリセットするリセットステップを含むとしてもよい。
　また、前記複数の電子制御ユニットは、前記車両の制御用途により分類された複数のグループの一に属し、前記複数のグループのそれぞれにおける前記所定状態は、前記複数のグループごとに定められてもよい。
　また、本開示の一態様の車載ネットワークシステムは、複数の電子制御ユニットを有し、車両に搭載される車載ネットワークシステムであって、前記複数の電子制御ユニットの少なくとも一つから送信される前記車両の走行に関する情報である走行情報を取得する取得部と、前記走行情報により得られる前記車両の走行に関する状態が所定状態であることを条件として、前記車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コードであって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵（ＭＡＣ：Message Authentication Code）を更新する更新処理部とを備える。
　また、本開示の一態様の電子制御ユニットは、車両に搭載される車載ネットワークシステムに接続される電子制御ユニットであって、ＣＰＵとメモリとを有し、前記ＣＰＵは、複数の電子制御ユニットの少なくとも一つから送信される前記車両の走行に関する情報である走行情報を取得して前記メモリに格納し、前記ＣＰＵは、前記メモリに格納された前記走行情報により得られる前記車両の走行に関する状態が所定状態であることを条件として、前記車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コードであって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵（ＭＡＣ：Message Authentication Code）を更新する。
　以下、図面を参照しながら、実施の形態について説明する。なお、以下で説明する実施の形態は、いずれも本開示の一具体例を示すものである。つまり、以下の実施の形態で示される数値、形状、材料、構成要素、構成要素の配置および接続形態、ステップ、ステップの順序などは、一例であり、本開示を限定する主旨ではない。また、以下の実施の形態における構成要素のうち、最上位概念を示す独立請求項に記載されていない構成要素は、任意で含まれる構成要素として説明される。
　（実施の形態）
　以下では、図面を参照しながら、実施の形態における更新処理方法等の説明を行う。なお、以下の説明においてメッセージ認証コードを、ＭＡＣ（Message Authentication Code）と称して説明をする。
　［１．システムの構成］
　図１は、本実施の形態における車載ネットワークシステム１００の構成を示すブロック図である。図２は、図１に示す鍵更新管理装置の構成の一例を示すブロック図である。
　本実施の形態における車載ネットワークシステム１００は、複数の電子制御ユニット（ＥＣＵ）を有し、車両に搭載される。図１において、車載ネットワークシステム１００は、鍵更新管理装置１０と、複数のＥＣＵとを備える。複数のＥＣＵ間、複数のＥＣＵおよび鍵更新管理装置の間は、ネットワークで接続されている。ネットワークは、上記のＣＡＮであってもよいし、Ｅｔｈｅｒｎｅｔ（登録商標）等のＬＡＮであってもよい。
　鍵更新管理装置１０は、車両の動作に応じて適切な頻度で鍵更新処理を行う。鍵更新管理装置１０は、例えば、ゲートウェイであってもよいし、複数のＥＣＵのうちの一つであってもよい。鍵更新管理装置１０は、図２に示すように、取得部１１と鍵更新部１２と鍵更新処理判定部１３とを備える。
　取得部１１は、複数の電子制御ユニットの少なくとも一つから送信される車両の走行に関する情報である走行情報を取得する。走行情報により車両の走行距離等が得られる。
　鍵更新処理判定部１３は、鍵更新部１２が鍵更新処理を実行する条件を満たしたか否かを判定する。
　鍵更新部１２は、走行情報により得られる車両の走行に関する状態が所定状態であることを条件として、車載ネットワークシステム１００において授受されるデータに付加されるＭＡＣであって改ざん防止のコードであるＭＡＣの生成に利用される鍵であるＭＡＣ鍵を更新する。なお、鍵更新部１２は、走行情報により得られる車両の走行に関する状態が所定状態であることを条件として送信カウンタおよび受信カウンタをリセットするとしてもよい。
　鍵更新部１２は、鍵更新処理を実行する条件を満たしたタイミングを通知することで、複数のＥＣＵすべてにＭＡＣ鍵を同一のタイミングで更新させる鍵更新処理を行ってもよい。また、鍵更新部１２は、鍵更新処理を実行する条件を満たしたタイミングにおいて生成した新たなＭＡＣ鍵を複数のＥＣＵすべてに配布することにより、複数のＥＣＵすべてにＭＡＣ鍵を同一のタイミングで更新させる鍵更新処理を行ってもよい。なお、鍵更新処理を実行する条件を満たしたタイミングを通知することは必須ではなく、ＣＡＮであれば複数のＥＣＵすべてがそれぞれ独立にタイミングを判定しても、複数のＥＣＵすべてが同一のタイミングで更新することになるからである。
　以下、本実施の形態における車載ネットワークシステム１００の全体構成の一例について説明する。
　［１．１　車載ネットワークシステム１００ａの全体構成］
　図３は、本実施の形態における車載ネットワークシステム１００ａの全体構成の一例を示す図である。車載ネットワークシステム１００ａは、上記の車載ネットワークシステム１００の一例である。複数の電子制御ユニットであるＥＣＵ１１１、ＥＣＵ１２１、ＥＣＵ１３１、ＥＣＵ１４１、ＥＣＵ１５１、ＥＣＵ１６１、ＥＣＵ１７１、ＥＣＵ１８１、ＥＣＵ１８２、ＥＣＵ１８４、ＥＣＵ１９１、および、ゲートウェイ１０１が車載ネットワークで接続されている。ここで、車載ネットワークは、ＣＡＮであってもよいし、Ｅｔｈｅｒｎｅｔ（登録商標）であってもよいし、ＣＡＮとＥｔｈｅｒｎｅｔが混在していてもよい。
　車載ネットワークには、例えば、エンジン１１０、トランスミッション１２０、および、図示しないモータ、燃料、電池の制御に関連する駆動系のＥＣＵが接続されている。図３に示すように、車載ネットワークには、エンジン１１０用のＥＣＵ１１１およびトランスミッション１２０用のＥＣＵ１２１が接続されている。
　また、車載ネットワークには、ブレーキ１３０およびステアリング１４０などの曲がる、止まるに関連するシャーシ系ＥＣＵが接続されている。図３に示すように、車載ネットワークには、ブレーキ１３０用のＥＣＵ１３１ステアリング１４０用のＥＣＵ１４１が接続されている。
　また、車載ネットワークには、自動ブレーキ１５０、車線維持装置１６０、および、図示しない車間距離機能、衝突防止機能、エアバッグなどの安全快適機能系ＥＣＵが接続されている。図３に示すように、車載ネットワークには、自動ブレーキ１５０用のＥＣＵ１５１と、車線維持装置１６０用のＥＣＵ１６１とが接続されている。
　また、車載ネットワークには、車車間通信装置１７０などに関連する通信系ＥＣＵが接続されている。図３に示すように、車載ネットワークには、車車間通信装置１７０用のＥＣＵ１７１が接続されている。車車間通信装置１７０は、他の車両からコンテンツデータを取得する。ＥＣＵ１７１は、取得したコンテンツデータを用いて自動運転などの動作処理を行う。
　また、車載ネットワークには、ヘッドユニット１８０などインフォテイメント系ＥＣＵが接続されている。図３に示すように、車載ネットワークには、ヘッドユニット１８０用のＥＣＵ１８１が接続されている。なお、ヘッドユニット１８０用のＥＣＵ１８１がなく、ヘッドユニット１８０がＥＣＵ１８１を介さず直接車載ネットワークに接続されていてもよい。
　また、車載ネットワークには、高度道路交通システムであるＩＴＳ（Intelligent Transport Systems）装置１９０用のＥＣＵ１９１が接続されている。図３に示すように、車載ネットワークには、ＩＴＳ装置１９０用のＥＣＵ１９１が接続されている。ＩＴＳ装置１９０は、道路情報だけでなく、道路および建物などの静的な地物を載せた地図データなどを外部のサーバから受信する。またＩＴＳ装置１９０は、センサ情報およびＧＰＳ（Global Positioning Syastem）による位置情報、カメラの画像情報などを外部のサーバに送信することで、外部のサーバが道路状況などの確認ができる。
　また、車載ネットワークには、ウィンドウ開閉センサ１８３、ドア開閉センサ１８５およびＧＰＳセンサ１８７などが接続されている。図３に示すように、車載ネットワークには、ウィンドウ開閉センサ１８３用のＥＣＵ１８２と、ドア開閉センサ１８５用のＥＣＵ１８４と、ＧＰＳセンサ１８７用のＥＣＵ１８６とが接続されている。なお、図示しない各種センサおよびカメラの画像情報なども車載ネットワークには接続されている。
　このような複数の電子制御ユニットは、接続されたものの状態等を取得し、定期的に取得した状態等を表すフレームを車載ネットワークに送信する。
　［１．２　データフレームフォーマット］
　図４は、ＣＡＮプロトコルのデータフレームのフォーマットを示す図である。ここではＣＡＮプロトコルにおける標準ＩＤフォーマットにおけるデータフレームを示している。
　図４に示すように、データフレームは、Start Of Frame（以下、ＳＯＦ）と、ＩＤフィールド、Remote Transimission Request（以下、ＲＴＲ）、Identifier Extension（以下、ＩＤＥ）、予約ビット（ｒ）、データレングスコード（以下、ＤＬＣ）、データフィールド、Cycric Redundancy Check（以下、ＣＲＣ）シーケンス、ＣＲＣデリミタ（図中、左のＤＥＬ）と、Acknowledgement（以下、ＡＣＫ）スロットと、ＡＣＫデリミタ（図中、右のＤＥＬ）と、エンドオブフレーム（以下、ＥＯＦ）とから構成される。
　ＳＯＦは、１ビットのドミナントである。バスがアイドルのときはレセシブになっている。送信ノードはバスをレセシブからドミナントへ変更することでフレームの送信開始を通知する。
　ＩＤは、１１ビット長の値で、データフレームの種類を示す。ここでいうデータフレームの種類とは、例えばデータの内容またはデータフレームの送信元である送信ノードを指す。また、ＩＤは、同一ネットワーク上で複数のノードが同時にデータフレームの送信を開始した場合の通信調停にも用いられる。より具体的には、ＩＤがより小さい値を持つデータフレームはより優先されて送信される。
　ＲＴＲは、１ビットのドミナントで、データフレームであることを示す。
　ＩＤＥおよびｒは、それぞれ１ビットのドミナントである。
　ＤＬＣは、４４ビット長の値で、続くデータフィールドの長さを示す。
　データフィールドは、最大６４ビット長で送信されるデータの部分であり、データフレームのペイロードである。長さは８ビット単位で調整可能である。送信されるデータの部分への割り当てに関する仕様は、車種および製造者の少なくとも一方に依存する。
　ＣＲＣシーケンスは、１５ビット長で、ＳＯＦ、ＩＤフィールド、コントロールフィールド、および、データフィールドの送信値より算出される値を示す。受信ノードは、各データフレームについてＳＯＦ、ＩＤフィールド、コントロールフィールド、および、データフィールドの受信値から算出した結果をＣＲＣシーケンスの値と比較することで異常の有無を判断する。
　ＣＲＣデリミタは、１ビットのレセシブで、ＣＲＣシーケンスの終了を表す区切り記号である。
　ＡＣＫスロットは、１ビット長であり、送信ノードはこの部分でレセシブを送信する。受信ノードはＣＲＣシーケンスまで正常に受信ができていれば、この部分でドミナントを送信する。ＣＡＮの規格では、同時に送信されたドミナントとレセシブとでは上述のとおりドミナントが優先される。そのため、通信が正常に行われている車載ネットワークシステムでは、ＡＣＫスロットの送信中、バスはドミナントの状態である。
　ＡＣＫデリミタは、１ビット長さのレセシブで、ＡＣＫスロットの終了を表す区切り記号である。
　ＥＯＦは、７ビット長さのレセシブで、データフレームの終了を示す。
　［１．３　メッセージ認証コード（ＭＡＣ）の送信］
　図５は、ＣＡＮ通信におけるＭＡＣの送信方法の一例を示す図である。図５の（ａ）には、ＣＡＮ通信に用いられるデータフレームが示され、図４と同一となっている。図５の（ｂ）には、ＭＡＣの送信に用いられる検証用データフレームが示されている。
　図５の（ｂ）に示すように、ＭＡＣは、図５の（ａ）に示す通常のデータフレームのデータフィールドをＭＡＣとした検証用データフレームにより送信される。つまり、通常のデータフレームに続けて、当該データフレームおけるデータフィールドをＭＡＣとした検証用データフレームを送信する。より具体的には、複数の電子制御ユニットのうちの一である第１電子制御ユニットが、ＣＡＮプロトコルに従ってバスを介して、データとしてデータフレーム、および、データに付加されるＭＡＣとしてデータフレームのデータフィールドをＭＡＣとした検証用データフレームの送信を行う。
　なお、詳細は後述するが、第１電子制御ユニットが、データフレームを識別するためのＩＤと送信カウンタによりカウントされたデータフレームの送信回数とを少なくとも結合した値に対して、ＭＡＣ鍵を用いてＭＡＣを生成する。また、複数の電子制御ユニットのうちの第１電子制御ユニット以外の複数の電子制御ユニットの少なくとも一である第２電子制御ユニットが、第１電子制御ユニットにより送信されたデータフレーム、および、検証用データフレームを、バスを介して受信する。そして、第２電子制御ユニットが、検証用データフレームを受信して得たＭＡＣと、受信したデータフレームに対応するＩＤと、受信カウンタによりカウントされたデータの受信回数とを少なくとも結合した値に対して、ＭＡＣ鍵を用いて生成したＭＡＣとの同一性を検証する。
　なお、検証用フレームは、データフレームに付加されるＭＡＣの一例であり、これに限られない。データフレームに付加されるＭＡＣとしては、通常のデータフレームにＭＡＣを追加する方法であってもよい。例えばデータフィールドの８バイトのうち、４バイトのみデータの送信用として用いられる場合、データフィールドの残りの４バイトに、ＭＡＣ値の１６バイトのうち、上位または下位の４バイトのみを付加される場合が考えられる。また、データフィールドの残りの４バイトに、ＭＡＣ値の１６バイトのうち、１バイトのみを付加する場合も考えられる。
　図６は、イーサネット（登録商標）通信におけるＭＡＣの送信方法の一例を示す図である。図６の（ａ）には、イーサネット（登録商標）通信において送信される情報の固まりであるＭＡＣフレーム(Media Access Control Frame)が示されている。ＭＡＣフレーム（以下、フレームともいう）は、イーサネット（登録商標）通信において送信すべき通信データが一定の長さ以下に分割されたデータと、ヘッダ、送信元アドレスおよび送信先アドレス等とを含む、決められた形式による情報の固まりである。図６の（ｂ）には、ＭＡＣの送信に用いられるＭＡＣフレームの一例が示されている。つまり、ＭＡＣフレームをＡＥＳなどの暗号方式で鍵（ＭＡＣ鍵と呼ぶ）を用いて暗号化したものをメッセージ認証コード（つまりＭＡＣ）としてペイロード部分に含めてＭＡＣフレームを送信することでＭＡＣを送信する。より具体的には、複数の電子制御ユニットのうちの一である第１電子制御ユニットが、ＭＡＣフレームに付加されるＭＡＣとしてペイロード部分にＭＡＣを含めて、ＭＡＣフレームの送信を行う。
　なお、第１電子制御ユニットが、ＭＡＣフレームに付加された送信元アドレスおよび送信先アドレスと送信カウンタによりカウントされたＭＡＣフレームの送信回数とを少なくとも結合した値に対してＭＡＣ鍵を用いＭＡＣを生成する。また、複数の電子制御ユニットのうちの第１電子制御ユニット以外の複数の電子制御ユニットの少なくとも一である第２電子制御ユニットが、第１電子制御ユニットにより送信されたＭＡＣフレームを受信する。そして、第２電子制御ユニットが、ペイロード部分にＭＡＣが含まれたフレームを受信して得たＭＡＣと、受信した当該ＭＡＣフレームに付加された送信元アドレスおよび送信先アドレスと受信カウンタによりカウントされたＭＡＣフレームの受信回数とを少なくとも結合した値に対して、ＭＡＣ鍵を用いて生成したＭＡＣとの同一性を検証する。
　なお、図６の（ｂ）にはＭＡＣフレームのペイロードにおけるデータ部分を暗号化した場合の例が示されているが、データ部分を暗号化することは必須ではない。また、ＭＡＣフレームに、その種類等を識別するためのＩＤが付加または含まれる場合には、ＭＡＣフレームに付加された送信元アドレスおよび送信先アドレスに代えて、ＭＡＣフレームを識別するためのＩＤと送信カウンタによりカウントされたデータフレームの送信回数とを少なくとも結合した値に対して、ＭＡＣ鍵を用いてＭＡＣを生成してもよいのはいうまでもない。
　［１．４　ＥＣＵ１１１の構成］
　図３に示す車載ネットワークに接続されるＥＣＵ１１１が、鍵更新管理装置１０として機能する場合について、以下説明する。
　図７は、本実施の形態におけるＥＣＵ１１１の機能構成を示すブロック図である。
　ＥＣＵ１１１は、車両に搭載される車載ネットワークに接続される電子制御ユニットであって、ＣＰＵ（Central Processing Unit）とメモリとを有する。ＥＣＵ１１１は、図７に示すように、フレーム送受信部１１１１と、フレーム解釈部１１１２と、受信ＩＤ判断部１１１３と、受信ＩＤリスト保持部１１１４と、フレーム処理部１１１５と、車体状態保持部１１１６と、判定ルール保持部１１１７と、タイマー１１１８と、鍵更新判定部１１１９と、更新処理部１１２０と、ＭＡＣ鍵保持部１１２１と、カウンタ保持部１１２２と、ＭＡＣ生成部１１２３と、フレーム生成部１１２４と、データ取得部１１２５とを備える。なお、車体状態保持部１１１６、判定ルール保持部１１１７、タイマー１１１８および鍵更新判定部は、鍵更新処理判定部１３の一例である鍵更新処理判定部１３ａを構成する。また、更新処理部１１２０、ＭＡＣ鍵保持部１１２１、カウンタ保持部１１２２およびＭＡＣ生成部１１２３は、鍵更新部１２の一例である鍵更新部１２ａを構成する。
　これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ１１１における通信回路、メモリに格納された制御プログラムを実行するプロセッサあるいはデジタル回路等により実現される。なお、ＥＣＵ１３１～ＥＣＵ１９１も同様の構成を備え、鍵更新管理装置１０として機能する。また、以下では、車載ネットワークがＣＡＮであるとして説明する。
　＜フレーム送受信部１１１１＞
　フレーム送受信部１１１１は、バスに対して、ＣＡＮのプロトコルに従ったフレームを送受信する。また、フレーム送受信部１１１１は、バスからフレームを１ビットずつ受信し、フレーム解釈部１１１２に転送する。また、フレーム送受信部１１１１は、フレーム生成部１１２４より通知を受けたフレームの内容をバスに送信する。
　＜フレーム解釈部１１１２＞
　フレーム解釈部１１１２は、フレーム送受信部１１１１により転送されて受け取ったフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。
　フレーム解釈部１１１２は、ＩＤフィールドと解釈した値を受信ＩＤ判断部１１１３へ通知する。フレーム解釈部１１１２は、受信ＩＤ判断部１１１３から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドの値とを、フレーム処理部１１１５に転送する、または、当該判定結果が通知された以降において解釈を中止することでフレームの受信を中止する。
　フレーム解釈部１１１２は、ＩＤフィールド以降に現れるデータフィールドの値をフレーム処理部１１１５に転送する場合、その後に受け取ったフレームの値から解釈したデータフレーム内のＡＣＫスロットの内容をフレーム処理部１１１５へ通知する。
　一方、フレーム解釈部１１１２は、受け取ったフレームの値から、当該フレームがＣＡＮプロトコルに則っていないフレームであると解釈した場合、フレーム生成部１１２４にエラーフレームを送信する旨の指示を通知する。
　フレーム解釈部１１１２は、受け取ったフレームの値から、当該フレームがエラーフレームであると解釈した場合、それ以降は、当該フレームの解釈を中止し、当該フレームを破棄する。
　＜受信ＩＤ判断部１１１３＞
　受信ＩＤ判断部１１１３は、フレーム解釈部１１１２から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部１１１４に保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。受信ＩＤ判断部１１１３は、判定結果を、フレーム解釈部１１１２に通知する。
　＜受信ＩＤリスト保持部１１１４＞
　受信ＩＤリスト保持部１１１４は、ＥＣＵ１１１が受信するＩＤ（メッセージＩＤ）のリストである受信ＩＤリストを保持する。受信ＩＤリストの一例を図８を用いて説明する。
　図８は、本実施の形態における受信ＩＤリストの一例を示す図である。図８には、例えば、ＥＣＵ１１１、ＥＣＵ１３１、ＥＣＵ１８２、ＥＣＵ１８４およびＥＣＵ１８６が受信するメッセージＩＤリストの一例が示されており、メッセージＩＤ「１」、「２」、「３」、「４」を受信する設定が表されている。
　＜フレーム処理部１１１５＞
　フレーム処理部１１１５は、フレーム解釈部１１１２より受信した全てのデータフレームに付加される、改ざん防止のコードであるＭＡＣを検証する。このＭＡＣの検証は、データフレーム（メッセージ）の正当性を検証する意義を有する。
　例えば、フレーム処理部１１１５は、受信したデータフレームのメッセージＩＤに対応したＭＡＣ鍵をＭＡＣ鍵保持部１１２１より取得し、当該メッセージＩＤに対応したカウンタ値をカウンタ保持部１１２２より取得することで、当該データフレームに続いて受信した検証用データフレームのデータフィールドに含まれるＭＡＣを検証する。
　具体的には、フレーム処理部１１１５は、検証用データフレームを受信して得たＭＡＣと、受信したデータフレームに対応するＩＤと、受信カウンタによりカウントされたデータの受信回数とを少なくとも結合した値に対して、ＭＡＣ鍵を用いて生成したＭＡＣとの同一性を検証する。本実施の形態では、フレーム処理部１１１５は、まず、ＭＡＣ生成部１１２３と同様の方法（後述）を用いて、ＭＡＣを計算により生成し、続いて、生成したＭＡＣと当該検証用データフレームのデータフィールドに含まれるＭＡＣとを比較する。そして、フレーム処理部１１１５は、両ＭＡＣが一致すれば検証に成功したと判定し、一致しなければ検証に失敗した、つまりエラーと判定する。フレーム処理部１１１５は、エラーと判定すれば、フレーム解釈部１１１２へ通知して、以降の受信処理を中止する。
　このように、フレーム処理部１１１５は、ＭＡＣの検証を行うので、バスに接続された不正ＥＣＵにより送信された不正なフレームを受信したとしてもエラーと判定し受信処理を中止できるので、不正なフレームによる車両の制御等を阻止することができる。
　また、フレーム処理部１１１５は、車両の状態（以降、車両状態）および／または走行情報を通知するフレームを受信した場合、車体状態保持部１１１６に受信した車両状態および／または走行情報を通知する。
　ここで、車両状態は、例えば、「走行中」、「停車中」または「駐車中」であり、車両が走行中か走行中に移り得る状態かを示す。車両状態は、例えば、トランスミッション１２０に接続されるＥＣＵ１２１が、トランスミッション１２０から得た例えばパーキング、ニュートラル、１速、２速などのギアポジションに基づいて特定し、フレームに含めてバスに通知するものでもよい。また、車両状態は、例えば、図３に不図示のＥＣＵが、複数のＥＣＵから通知された情報に基づいて車両状態を特定し、フレームに含めてバスに通知するものでもよい。
　走行情報は、車両の走行に関する情報であり、例えばＧＰＳセンサ１８７が取得した位置、または、他のセンサにより検出した車両の走行距離もしくは走行時間でもよいし、ＥＣＵ１１１がエンジン１１０から取得した車速および当該車速の時間などである。このように、フレーム処理部１１１５は、上述した取得部１１の機能を有し、複数の電子制御ユニットの少なくとも一つから送信される車両の走行に関する情報である走行情報を取得する。
　また、フレーム処理部１１１５は、受信したフレームのデータに応じた処理を行う。ＥＣＵ１１１が車両の搭乗者に対してアラーム音を鳴らすためのスピーカ等を有するなどアラーム音を鳴らす機能を有しているとする。そして、例えば走行情報またはエンジン１１０等から得た情報により得られる車両の時速が３０ｋｍを超えた状況でドアが開いている旨を示す情報を受信する場合には、フレーム処理部１１１５は、車両の搭乗者に対してアラーム音を鳴らしてもよい。このように、フレーム処理部１１１５は、他のＥＣＵから受信した、例えばドアの状態を通知するデータフレームを管理し、エンジン１１０より得られる車速に基づいて一定条件下でアラーム音を鳴らす処理を行うなど、受信したフレームのデータに応じた処理を行う。なお、フレーム処理部１１１５は、複数のＥＣＵで共通するとして説明したがＥＣＵ毎に異なる処理を行ってもよい。例えば、ブレーキがかかっていない状況でドアが開いた場合に、ＥＣＵ１８４は、車両の搭乗者に対してアラーム音を鳴らす処理を行う一方で、ＥＣＵ１３１、ＥＣＵ１８２等は、アラーム音を鳴らす処理を行わないとしてもよい。ＥＣＵ１１１～ＥＣＵ１８６は、アラーム音を鳴らす機能以外の機能をそれぞれ備えてもよいし備えないでもよい。
　また、フレーム処理部１１１５は、フレーム解釈部１１１２より受信したデータフレーム内のＡＣＫスロットの値を確認し、フレーム送受信部１１１１から送信したフレームが、他のＥＣＵで正常に受信されているかどうかを確認する。そして、フレーム処理部１１１５は、確認した結果を更新処理部１１２０に通知する。
　＜車体状態保持部１１１６＞
　車体状態保持部１１１６は、フレーム処理部１１１５より通知された現在の車両状態および現在の走行状態を保持する。この結果、車体状態保持部１１１６は、現在までに通知された車両状態および走行情報を保持することになる。具体的には、車体状態保持部１１１６は、車両状態として、上述したが例えば「走行中」、「停車中」、「駐車中」を保持する。また、走行情報として、上述したが例えば走行距離、車速、および車両の位置を示すＧＰＳ情報を保持する。
　車体状態保持部１１１６は、走行情報により得られる走行距離であってＭＡＣ鍵の前回の更新時からの車両の走行距離が閾値を超えた状態になった場合に、鍵更新判定部１１１９に通知する。ここで、走行情報により得られる走行距離は、他のセンサにより検出した車両の走行距離でもよいし、ＧＰＳセンサ１８７が取得した位置により計算される移動距離でもよいし、エンジン１１０から取得した車速および当該車速の時間から計算される距離でもよい。
　＜判定ルール保持部１１１７＞
　判定ルール保持部１１１７は、鍵更新判定部１１１９により用いられる判定ルールを保持する。ここで、判定ルールは、更新処理部１１２０が更新処理を実行する条件を満たしたか否かを判定するためのルールである。以下、判定ルールの一例を図９Ａおよび図９Ｂを用いて説明する。
　図９Ａおよび図９Ｂは、本実施の形態における判定ルールの一例を示す図である。図９Ａには車両状態に応じた判定ルールの一例が示され、図９Ｂには走行情報に応じた判定ルールの一例が示されている。
　図９Ａでは、車両状態が「走行中」または「停車中」である場合、更新処理を実施しない判定ルールが示されている。一方、車両状態が「駐車中」である場合、更新処理を実施する判定ルールが示されている。つまり、図９Ａに示す判定ルールによれば、例えば車両状態が「走行中」または「停車中」であるとき、ＭＡＣ鍵更新の更新タイミングが到来しても更新処理部１１２０が更新処理を実行する条件を満たさないと判定され、更新処理されない。そして、車両状態が「駐車中」に変わったときに、更新処理部１１２０が更新処理を実行する条件を満たすと判定され、更新処理が実行される。また、車両状態が「駐車中」であるときに、ＭＡＣ鍵更新の更新タイミングが到来すれば更新処理部１１２０が更新処理を実行する条件を満たすと判定される。
　図９Ｂでは、車両の走行距離が閾値Ｄ１以下であれば更新処理を実施せずに、閾値Ｄ１より上であれば更新処理を実施する判定ルールが示されている。また、ＧＰＳによる車両の移動距離が閾値Ｄ２以下であれば更新処理を実施せず、閾値Ｄ２より上であれば更新処理を実施する判定ルールが示されている。なお、ＧＰＳによる車両の移動距離は、走行情報に含まれるＧＰＳセンサ１８７が取得した位置により得られる。つまり、ＧＰＳによる車両の移動距離は、走行情報により得られる車両の走行距離に含まれるとしてもよい。このように、車両の走行距離が閾値Ｄ１以下、または、ＧＰＳによる車両の移動距離が閾値Ｄ２以下であれば、更新処理部１１２０が更新処理を実行する条件を満たさないと判定され、更新処理されない。車両の走行距離が閾値Ｄ１より上、または、ＧＰＳによる車両の移動距離が閾値Ｄ２より上であれば、ＭＡＣ鍵更新の更新タイミングが到来する前であっても更新処理部１１２０が更新処理を実行する条件を満たすと判定され、更新処理される。
　なお、更新処理部１１２０が更新処理を実行する条件を満たしたか否かの判定は、車両状態と走行情報の判定ルールのいずれかの判定ルールに従って行うとしてもよいし、車両状態と走行情報の両方の判定ルールに従って行うとしてもよい。
　例えば、図９Ａに示す車両状態と図９Ｂに示す走行情報の両方の判定ルールに従って、例えば車両状態が走行中、または、走行距離が閾値Ｄ１以下の場合には、更新処理部１１２０が更新処理を実行する条件を満たさないと判定され、更新処理がされないとしてもよい。
　また、車両状態の判定ルールと走行状態の判定ルールとが、相反する等で異なり、更新処理の判定ができない場合は、更新処理部１１２０が更新処理を実行する条件を満たしていないと判定されるとしてもよい。
　＜タイマー１１１８＞
　タイマー１１１８は、経過時間に対応するタイマー値のカウントアップを繰り返す計時機構である。タイマー１１１８は、ＭＡＣ鍵の前回の更新処理完了時からの経過時間を鍵更新判定部１１１９へ通知する。また、タイマー１１１８は、鍵更新判定部１１１９からの更新処理の完了通知に基づいて、タイマー値のリセットを行う。
　＜鍵更新判定部１１１９＞
　鍵更新判定部１１１９は、更新処理部１１２０が更新処理を実行する条件を満たしているか否かを判定する。また、鍵更新判定部１１１９は、ＭＡＣ鍵更新の更新タイミングが到来したかを判定してもよい。ここで、更新タイミングとは、予め定められた一定時間（例えば６時間、１日等）が経過したタイミングであり、タイマー１１１８に基づき、判定される。更新処理部１１２０が更新処理を実行する条件とは、走行情報により得られる車両の走行に関する状態が所定状態であることを満たすことである。所定状態とは、ＭＡＣ鍵更新の更新タイミングが到来する前であれば、走行情報により得られる車両の走行距離であってＭＡＣ鍵の前回の更新時からの車両の走行距離が閾値を超えた状態である。または、所定状態とは、ＭＡＣ鍵更新の更新タイミングが到来した後であれば、車両の状態が駐車中である状態である。
　本実施の形態では、鍵更新判定部１１１９は、タイマー１１１８に基づき、予め定められた更新タイミングが到来したとき、車体状態保持部１１１６から現在の車両状態を取得し、判定ルール保持部１１１７から取得した判定ルールに応じて、更新処理部１１２０が更新処理を実行する条件を満たすか否かを判定する。ここで、更新処理とは、ＭＡＣ鍵の更新処理を少なくとも含み、ＭＡＣの生成に利用されるデータの更新に関連する更新処理も含む。より具体的には、更新処理は、ＭＡＣを生成するために用いる鍵であるＭＡＣ鍵の値を更新する鍵更新処理と、ＭＡＣに反映するカウンタ値をリセット（つまりゼロ等の特定値に更新）するカウンタリセット処理とを意味する。
　そして、この場合、鍵更新判定部１１１９は、更新処理部１１２０が更新処理を実行する条件を満たすと判定したとき、更新処理部１１２０へその旨を通知する。一方、鍵更新判定部１１１９は、更新処理部１１２０が更新処理を実行する条件を満たさないと判定したときには、車両状態の変化を待つ。
　また、鍵更新判定部１１１９は、予め定められた更新タイミングが到来していなくても、車体状態保持部１１１６から現在を含む走行情報を取得し、判定ルール保持部１１１７から取得した判定ルールに応じて、更新処理部１１２０が更新処理を実行する条件を満たすか否かを判定する。鍵更新判定部１１１９は、更新処理部１１２０が更新処理を実行する条件を満たすと判定したとき、更新処理部１１２０へその旨を通知する。一方、鍵更新判定部１１１９は、更新処理部１１２０が更新処理を実行する条件を満たさないと判定したときには、予め定められた更新タイミングが到来するまで待って、車両状態に基づく判定を行えばよい。
　また、鍵更新判定部１１１９は、更新処理が完了した場合、タイマー１１１８にタイマー値のリセットを行わせるために、タイマー１１１８に更新処理の完了通知を通知する。
　＜更新処理部１１２０＞
　更新処理部１１２０は、鍵更新判定部１１１９からの通知に従って更新処理を行う。すなわち、更新処理部１１２０は、走行情報により得られる車両の走行に関する状態が所定状態であることを条件として、ＭＡＣ鍵を更新する更新処理を行う。
　例えば更新処理部１１２０は、当該所定状態であるという鍵更新処理を実行する条件を満たしたタイミングを通知することで、自ＥＣＵ１１１を含む複数のＥＣＵすべてにＭＡＣ鍵を同一のタイミングで更新させる鍵更新処理を行ってもよい。つまり、更新処理部１１２０は、複数のＥＣＵのすべてが、上記条件を満たした同一のタイミングで、ＭＡＣ鍵を用いて新たなＭＡＣ鍵を生成するとしてもよい。そして、更新処理部１１２０は、上記条件を満たした同一のタイミングで送信カウンタおよび受信カウンタをリセットしてもよい。
　また、例えば鍵更新部１２は、上記条件を満たしたときに、ＭＡＣ鍵を用いて新たなＭＡＣ鍵を生成するとしてもよい。そして、鍵更新部１２は、上記条件を満たしたタイミングにおいて生成した新たなＭＡＣ鍵を、自ＥＣＵ１１１を除く複数のＥＣＵすべてに配布することにより、複数のＥＣＵすべてにＭＡＣ鍵を同一のタイミングで更新させる鍵更新処理を行ってもよい。同様に、更新処理部１１２０は、上記条件を満たした同一のタイミングで送信カウンタおよび受信カウンタをリセットしてもよい。
　本実施の形態では、更新処理部１１２０は、鍵更新判定部１１１９から更新処理部１１２０が更新処理を実行する条件を満たすと判定した旨の通知を受けて、新たにＭＡＣ鍵候補となる鍵を生成し、ＭＡＣ鍵保持部１１２１へ通知する。また、更新処理部１１２０は、当該通知を受けて、カウンタ保持部１１２２に対し、カウンタ値をリセットするよう通知する。なお、更新処理部１１２０は、当該通知を受けたとき、ＭＡＣ鍵保持部１１２１が保持していたＭＡＣ鍵を取得して旧鍵としてキャッシュ（つまり一時的に記憶媒体に保持）するとともに、カウンタ保持部１１２２が保持しているカウンタ値を取得してキャッシュする。
　更新処理部１１２０は、ＭＡＣ鍵の更新が複数のＥＣＵのうち一つでも成功しなかった場合、キャッシュしている旧鍵であるＭＡＣ鍵をＭＡＣ鍵保持部１１２１へ通知し、キャッシュしているリセット前のカウンタ値をカウンタ保持部１１２２へ通知する。
　一方、更新処理部１１２０は、ＭＡＣ鍵の更新が複数のＥＣＵすべてで成功した場合、キャッシュしている旧鍵であるＭＡＣ鍵と、リセット前のカウンタ値を削除する。なお、これらの削除は、一時的に保持していたこれらの値を以後使用できないものと扱うことができれば、図示しない一時記憶装置に記憶されている値の削除に限らない。
　なお、更新処理部１１２０は、ＭＡＣ鍵の生成方法として、例えば、旧鍵となる現在のＭＡＣ鍵を、例えばハッシュ関数等の予め定められた一方向関数に入力することで導出される結果を新たなＭＡＣ鍵候補とする方法を用いればよい。
　＜ＭＡＣ鍵保持部１１２１＞
　ＭＡＣ鍵保持部１１２１は、メモリ等の記憶媒体により実現され、ＭＡＣ鍵を、メッセージＩＤ毎に１つ保持する。保持されるＭＡＣ鍵は、上述したように、ＭＡＣ生成部１１２３およびフレーム処理部１１１５がＭＡＣを計算する際に必要となる。また、ＭＡＣ鍵保持部１１２１は、更新処理部１１２０からの通知に従って、これまで持っていたＭＡＣ鍵を破棄し、通知された新たなＭＡＣ鍵を保持することでＭＡＣ鍵を更新する。
　＜カウンタ保持部１１２２＞
　カウンタ保持部１１２２は、メモリ等の記憶媒体を含んで実現され、カウンタ値を、メッセージＩＤ毎に１つ保持する。カウンタ保持部１１２２は、更新処理部１１２０からの通知に従って、通知されたカウンタ値を保持し、また、更新処理部１１２０からのリセットすべき旨の通知に従って、保持しているカウンタ値をリセットする。このリセットによりカウンタ値は、ゼロ等の特定値に更新される。
　ここで、カウンタ値は、ＭＡＣ生成部１１２３およびフレーム処理部１１１５がＭＡＣを計算する際に必要となる。また、カウンタ値は、フレーム送受信部１１１１からフレームが正常に送信された場合にインクリメント（１増加）される。カウンタ値は、フレーム送受信部１１１１からデータフレームが送信される場合においては送信カウンタとして扱われ、送信回数がカウントされる。また、カウンタ値は、フレーム送受信部１１１１でデータフレームを受信する場合においては受信カウンタとして扱われ、受信回数がカウントされる。
　カウンタ保持部１１２２は、例えばメッセージＩＤが「１」のデータフレームをフレーム送受信部１１１１から送信する場合、保持するカウンタ値のうちメッセージＩＤが「１」に対応するカウンタ値を送信カウンタとして扱い、正常に１回送信される毎にインクリメントする。
　また、カウンタ保持部１１２２は、例えばメッセージＩＤが「１」のデータフレームをフレーム送受信部１１１１で受信する場合、保持するカウンタ値のうちメッセージＩＤが「１」に対応するカウンタ値を、受信カウンタとして扱い、正常に受信される毎にインクリメントする。
　＜ＭＡＣ生成部１１２３＞
　ＭＡＣ生成部１１２３は、データフレームを識別するためのＩＤと送信カウンタによりカウントされたデータフレームの送信回数とを少なくとも結合した値に対して、ＭＡＣ鍵を用いてＭＡＣを生成する。
　本実施の形態では、ＭＡＣ生成部１１２３は、フレーム生成部１１２４より通知されるメッセージＩＤとデータフィールド用のデータの値と、カウンタ保持部１１２２で保持するカウンタ値（つまりメッセージＩＤに対応するカウンタ値）とを結合した値（結合値）を算出する。そして、ＭＡＣ生成部１１２３は、算出した結合値に対し、ＭＡＣ鍵保持部１１２１で保持するＭＡＣ鍵（つまりメッセージＩＤに対応するＭＡＣ鍵）を用いて、ＭＡＣを算出（つまりＭＡＣの値を計算により導出）して、この算出した結果であるＭＡＣをフレーム生成部１１２４へと通知する。
　ここで、ＭＡＣの計算方法として、例えば非特許文献１に示されるＨＭＡＣ（Hash-based Message Authentication Code）を採用してもよい。この場合、ＭＡＣ生成部１１２３は、算出した結合値に対し、例えば４バイトの所定のブロック分までパディングした値でＭＡＣ鍵を使って計算し、出てきた計算結果の先頭４バイトをＭＡＣ値とすればよい。
　なお、本実施の形態で説明するＭＡＣ値のサイズ、計算方法は一例であり、これに限定されるものではない。また、ＭＡＣは、フレームが送信される毎にインクリメントされるカウンタ値を反映して生成される。つまり、たとえＥＣＵ１１１が同じデータの値を含むデータフレームを複数回送信したとしても、データフレームに付与（つまり付加）されるＭＡＣは送信毎に変化する。
　なお、上述したが、車載ネットワークがＥｔｈｅｒｎｅｔ（登録商標）である場合には、フレームには通常ＩＤが付与されず、代わりに送信元アドレスおよび送信先アドレスが付加されている。そのため、フレームに付加された送信元アドレスおよび送信先アドレスと送信カウンタによりカウントされたＭＡＣフレームの送信回数とを少なくとも結合した値に対してＭＡＣ鍵を用いＭＡＣを生成すればよい。
　＜フレーム生成部１１２４＞
　フレーム生成部１１２４は、フレーム解釈部１１１２から通知されたエラーフレームの送信を指示する通知に従い、エラーフレームを構成してフレーム送受信部１１１１へ通知する。
　また、フレーム生成部１１２４は、予め定められたメッセージＩＤとデータ取得部１１２５より通知されたデータの値（データフィールド用のデータの値）とをＭＡＣ生成部１１２３へ通知することによりＭＡＣの通知を受ける。そして、フレーム生成部１１２４は、予め定められたメッセージＩＤと、通知されたＭＡＣと、通知されたデータフィールド用のデータの値とに基づきフレームを構成してフレーム送受信部１１１１へ通知する。
　＜データ取得部１１２５＞
　データ取得部１１２５は、ＥＣＵにつながっている機器、センサ等の状態を示すデータを取得し、フレーム生成部１１２４に通知する。
　［１．５　送信されるフレームの例］
　以下、例えばＥＣＵ１１１、ＥＣＵ１３１、ＥＣＵ１８２、ＥＣＵ１８４およびＥＣＵ１８６のそれぞれが送信するフレームの一例について図１０～図１４を用いて説明する。
　＜ＥＣＵ１１１が送信するフレームの例＞
　図１０は、本実施の形態におけるエンジン１１０に接続されたＥＣＵ１１１が送信するメッセージＩＤと、データの一例を示す図である。図１０に示すように、ＥＣＵ１１１が送信するメッセージＩＤは例えば「１」である。そして、ＥＣＵ１１１が送信するデータフィールドの値のうち、先頭１バイトは時速を表し、次の１バイトはカウンタを表し、次の４バイトはＭＡＣ値を表している。時速は最低０ｋｍ～最高１８０ｋｍまでの範囲を取るとしている。つまり、ＥＣＵ１１１は、時速を表す先頭１バイトの値と、それぞれに対応したカウンタ値とＭＡＣ値とをセットにして６バイトで送信する。図１０では、車両が０ｋｍから１ｋｍずつ加速されている様子が示されている。
　＜ＥＣＵ１３１が送信するフレームの例＞
　図１１は、本実施の形態におけるブレーキ１３０に接続されたＥＣＵ１３１が送信するメッセージＩＤと、データの一例を示す図である。図１１に示すように、ＥＣＵ１３１が送信するメッセージＩＤは例えば「２」である。そして、ＥＣＵ１３１が送信するデータフィールドの値のうち、先頭１バイトはブレーキのかかり具合を％で表し、次の１バイトはカウンタを表し、次の４バイトはＭＡＣ値を表している。ブレーキを全くかけていない状態を０％とし、ブレーキを最大限かけている状態を１００％としている。つまり、ＥＣＵ１３１は、ブレーキのかかり具合を表す先頭１バイトの値と、それぞれの値に対応したカウンタ値と、ＭＡＣ値とをセットにして６バイトで送信する。図１１では、車両が１００％から徐々にブレーキを弱める様子が示されている。
　＜ＥＣＵ１８４が送信するフレームの例＞
　図１２は、本実施の形態におけるドア開閉センサ１８５に接続されたＥＣＵ１８４が送信するメッセージＩＤと、データの一例を示す図である。図１２に示すように、ＥＣＵ１８４が送信するメッセージＩＤは例えば「３」である。そして、ＥＣＵ１８４が送信するデータフィールドの値のうち、先頭の１バイトはドアの開閉状態を表し、次の１バイトはカウンタを表し、次の４バイトはＭＡＣ値を表している。ドアが開いている状態を「１」、ドアが閉まっている状態を「０」としている。つまり、ＥＣＵ１８４は、ドアの開閉状態を表す先頭１バイトの値と、それぞれの値に対応したカウンタ値と、ＭＡＣ値とをセットにして６バイトで送信する。図１２では、ドアが開いている状態から、途中で閉められた様子が示されている。
　＜ＥＣＵ１８２が送信するフレームの例＞
　図１３は、本実施の形態におけるウィンドウ開閉センサ１８３に接続されたＥＣＵ１８２が送信するメッセージＩＤと、データの一例を示す図である。図１３に示すように、ＥＣＵ１８２が送信するメッセージＩＤは例えば「４」である。そして、ＥＣＵ１８２が送信するデータフィールドの値のうち、先頭の１バイトは窓の開閉状態を％で表し、次の１バイトはカウンタを表し、次の４バイトはＭＡＣ値を表している。窓が閉まっている状態を０％、窓が全開の状態を１００％としている。つまり、ＥＣＵ１８２は、窓の開閉状態を表す先頭１バイトの値と、それぞれに対応したカウンタ値と、ＭＡＣ値とをセットにして６バイトで送信する。図１３では、窓が閉まっている状態から、徐々に開いていく様子が示されている。
　＜ＥＣＵ１８６が送信するフレームの例＞
　図１４は、実施の形態におけるＧＰＳセンサ１８７に接続されたＥＣＵ１８６が送信するメッセージＩＤと、データの一例を示す図である。図１４に示すように、ＥＣＵ１８２が送信するメッセージＩＤは例えば「５」である。そして、ＥＣＵ１８６が送信するデータフィールドの値のうち、先頭の３バイトはＧＰＳの差分を表し、次の１バイトはカウンタを表し、次の４バイトはＭＡＣ値を表す。つまり、ＥＣＵ１８６は、前回の位置からの差分値と、カウンタ値と、ＭＡＣ値とをセットとして８バイトで送信する。
　［１．６　更新処理］
　次に、車載ネットワークシステム１００の動作について説明する。
　図１５は、本実施の形態における更新処理方法を示すフローチャートである。以下では、車載ネットワークシステム１００を構成する鍵更新管理装置１０が更新処理を行うとして説明するが、これに限らない。各ＥＣＵが更新処理を行ってもよいし、全ＥＣＵの一が鍵更新管理装置１０として更新処理を行うとしてもよいし、車載ネットワークシステム１００ａを構成するゲートウェイ１０１が更新処理を行うとしてもよい。
　まず、鍵更新管理装置１０は、複数の電子制御ユニットの少なくとも一つから送信される、車両の走行に関する情報である走行情報を取得する（Ｓ１０）。
　次に、鍵更新管理装置１０は、走行情報により得られる車両の走行に関する状態が所定状態であるという条件を満たすか否かを判定する（Ｓ１１）。
　ステップＳ１１において、上記の条件を満たせば（Ｓ１１でＹ）、鍵更新管理装置１０は、車載ネットワークシステム１００において授受されるデータに付加されるＭＡＣ（メッセージ認証コード）であって改ざん防止のコードであるＭＡＣの生成に利用される鍵であるＭＡＣ鍵を更新する（Ｓ１２）。なお、ステップＳ１１において、上記の条件を満たさない場合（Ｓ１１でＮ）、ステップＳ１０に戻る。
　図１６は、図１５に示すステップＳ１１の詳細処理を示すフローチャートである。以下では、車載ネットワークシステム１００ａを構成する複数のＥＣＵの一であるＥＣＵ１１１が鍵更新管理装置１０として更新処理を実行する場合を例に挙げて説明する。
　ステップＳ１１において、ＥＣＵ１１１は、内部に持つタイマー１１１８により、前回の更新処理完了時からの経過時間を確認する（Ｓ１１０１）。
　次に、ＥＣＵ１１１は、前回の更新処理完了時から予め定められた一定時間経過しているかどうかを判定する（Ｓ１１０２）。より具体的には、ＥＣＵ１１１は、タイマー１１１８がカウントする経過時間に基づき、ＭＡＣ鍵更新の更新タイミングが到来したかを判定する。
　ステップＳ１１０２において、前回の更新処理完了時から一定時間が経過していない場合（Ｓ１１０２でＮ）、ＥＣＵ１１１は、前回の更新処理完了時から車両が走行した距離を確認する（Ｓ１１０３）。より具体的には、ＥＣＵ１１１は、走行情報により得られる車両の走行距離であってＭＡＣ鍵の前回の更新時からの車両の走行距離を確認する。
　次に、ＥＣＵ１１１は、前回の更新処理完了時から車両が走行した距離があらかじめ定められた閾値より大きいかを判定する（Ｓ１１０４）。例えば図９Ｂに示すような判定ルールに従い、ＥＣＵ１１１は、前回の更新処理完了時から車両が走行した距離が閾値より大きいかを判定する。
　ステップＳ１１０４において、ＥＣＵ１１１は、前回の更新処理完了時から車両が走行した距離が閾値以下の場合（Ｓ１１０４でＮ）、Ｓ１１０１へ戻る。
　一方、ステップＳ１１０４において、ＥＣＵ１１１は、前回の更新処理完了時から車両が走行した距離が閾値より大きい場合（Ｓ１１０４でＹ）、ステップＳ１１の処理を終了し、図１５に示すステップＳ１２に進む。なお、ステップＳ１１０４において、前回の更新処理完了時から車両が走行した距離が閾値以下の場合（Ｓ１１０４でＮ）、ＥＣＵ１１１は、図１５に示すステップＳ１０に戻る。
　また、ステップＳ１１０２において、前回の更新処理完了時から一定時間が経過している場合（Ｓ１１０２でＹ）、ＥＣＵ１１１は、現在の車両状態を確認し（Ｓ１１０５）、車両が駐車中であるか否かを判定する（Ｓ１１０６）。
　車両が駐車中であれば（Ｓ１１０６でＹ）、ＥＣＵ１１１は、ステップＳ１１の処理を終了し、図１５に示すステップＳ１２に進む。一方、車両が駐車中であれば（Ｓ１１０６でＮ）、ＥＣＵ１１１は、ステップＳ１１０５に戻る。
　なお、ステップＳ１１０４において、ＥＣＵ１１１は、前回の更新処理完了時から車両が走行した距離が閾値より大きい場合（Ｓ１１０４でＹ）、ステップＳ１１の処理を終了するとしたが、これに限らない。さらに、ステップＳ１１０５およびＳ１１０６の処理を行うとしてもよい。
　このように、ＥＣＵ１１１は、現在の車両状態または走行情報により得られる車両の走行距離であってＭＡＣ鍵の前回の更新時からの車両の走行距離から、判定ルール保持部１１１７に保持されている判定ルールに従って更新処理を実行するかどうかを判定することができる。
　例えば図９Ａに示した判定ルールに従う場合、ＥＣＵ１１１は、車両状態が「走行中」「停車中」であれば、更新処理を実行しない。一方、車両状態が「駐車中」であれば更新処理を実行する。また、図９Ｂに示した判定ルールに従う場合、ＥＣＵ１１１は、走行情報により得られる車両の走行距離であってＭＡＣ鍵の前回の更新時からの車両の走行距離が閾値Ｄ１以下であれば、更新処理を実行しない。また、ＧＰＳの移動距離で示される走行距離が閾値Ｄ２以下であれば、更新処理を実行しない。
　図１７は、図１５に示すステップＳ１２の詳細処理を示すフローチャートの一例である。図１７でも、図１６と同様に、車載ネットワークシステム１００ａを構成する複数のＥＣＵの一であるＥＣＵ１１１が更新処理を実行する場合を例に挙げて説明する。ここで、図１７には、鍵更新処理を実行する条件を満たしたタイミングにおいて生成した新たなＭＡＣ鍵を、自ＥＣＵ１１１を除く複数のＥＣＵすべてに配布することにより、複数のＥＣＵすべてにＭＡＣ鍵を同一のタイミングで更新させる更新処理が示されている。
　図１７に示すように、ステップＳ１２において、ＥＣＵ１１１は、ＭＡＣ鍵保持部１１２１が保持しているＭＡＣ鍵を、旧鍵としてキャッシュする（Ｓ１２０１）。続いて、ＥＣＵ１１１は、生成した鍵をＭＡＣ鍵とする（Ｓ１２０２）。より具体的には、ＥＣＵ１１１は、新たにＭＡＣ鍵候補となる鍵を生成して、ＭＡＣ鍵としてＭＡＣ鍵保持部１１２１に保持する。
　次に、ＥＣＵ１１１は、カウンタ保持部１１２２が保持しているカウンタ値を、キャッシュする（Ｓ１２０３）。続いて、ＥＣＵ１１１は、カウンタ保持部１１２２が保持しているカウンタ値をゼロにリセットする（Ｓ１２０４）。
　次に、ＥＣＵ１１１は、生成したＭＡＣ鍵を用いてＭＡＣを生成する（Ｓ１２０５）。より具体的には、ＥＣＵ１１１は、予め定められたメッセージＩＤと、データフィールド用のデータ値と、リセット後のカウンタ保持部１１２２が保持しているカウンタ値と、ＭＡＣ鍵保持部１１２１が保持している新たに生成したＭＡＣ鍵とを用いてＭＡＣを生成する。
　次に、ＥＣＵ１１１は、生成したＭＡＣ鍵を配布するためのデータフレームである鍵配布フレームを生成してブロードキャストし、続けて更新の同期を確認するためのデータフレームである更新フレームをブロードキャストする（Ｓ１２０６）。より具体的には、まず、ＥＣＵ１１１は、メッセージＩＤとデータフィールド用のデータ値とステップＳ１２０２において生成したＭＡＣ鍵とを含む鍵配布フレームを生成してバスへ送信を行い、自ＥＣＵ１１１を除く複数のＥＣＵすべてに同一タイミングでＭＡＣ鍵を更新させる。続けて、ＥＣＵ１１１は、メッセージＩＤとデータフィールド用のデータ値とステップＳ１２０５において生成したＭＡＣとを含む更新フレームを生成してバスへ送信する。なお、鍵配布フレームを受信した他のＥＣＵは、ＥＣＵ１１１同様に、旧鍵であるＭＡＣ鍵と、リセット前のカウンタ値とをキャッシュしている。
　次に、ＥＣＵ１１１は、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功したかどうかを判定する（Ｓ１２０７）。より具体的には、ＥＣＵ１１１は、ステップＳ１２０６において更新フレームをバスに送信後、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功（つまり正常に受信）したかどうかを、ＡＣＫスロットの値を見ることで判定する。
　ステップＳ１２０７において、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功したと判定した場合（Ｓ１２０７でＹ）、ＥＣＵ１１１は、キャッシュしていた旧鍵であるＭＡＣ鍵とリセット前のカウンタ値とを破棄して（Ｓ１２０８）、更新処理を終了する。自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功した場合、複数のＥＣＵすべてにおいて新たなＭＡＣ鍵によりＭＡＣ鍵の更新が完了したことがわかるからである。
　一方、ステップＳ１２０７において、更新フレームの受信に成功しなかった場合（Ｓ１２０７でＮ）、ＥＣＵ１１１は、キャッシュしておいた旧鍵であるＭＡＣ鍵を、再度ＭＡＣ鍵に設定し（Ｓ１２１０）、キャッシュしておいたリセット前のカウンタ値を再度設定する（Ｓ１２１１）。より具体的には、ＥＣＵ１１１は、更新フレームの受信に失敗したＥＣＵがあった場合、キャッシュしておいた旧鍵であるＭＡＣ鍵をＭＡＣ鍵保持部１１２１に保持させる。また、ＥＣＵ１１１は、キャッシュしておいたリセット前のカウンタ値を、再度カウンタ値としてカウンタ保持部１１２２に保持させる。なお、他のＥＣＵは、ＥＣＵ１１１同様に、キャッシュしておいた旧鍵であるＭＡＣ鍵を、再度ＭＡＣ鍵に設定し、キャッシュしておいたリセット前のカウンタ値を再度設定する。また、更新フレームの受信に成功しなかったＥＣＵがあった場合でも、再度鍵配布フレームをブロードキャストして新たなＭＡＣ鍵を再度配布した上で、更新フレームの受信に失敗したＥＣＵがあったかどうかを判定してもよい。
　次に、ＥＣＵ１１１は、再設定したＭＡＣ鍵とカウンタ値を用いてＭＡＣを生成する（Ｓ１２１２）。より具体的には、ＥＣＵ１１１は、予め定められたメッセージＩＤと、データフィールド用のデータ値と、キャッシュから再設定したカウンタ保持部１１２２のカウンタ値と、キャッシュから再設定したＭＡＣ鍵保持部１１２１のＭＡＣ鍵とを用いて、ＭＡＣを生成する。
　次に、ＥＣＵ１１１は、更新の同期を確認するためのデータフレームである更新フレームをブロードキャストする（Ｓ１２１３）。より具体的には、ＥＣＵ１１１は、メッセージＩＤとデータフィールド用のデータ値とステップＳ１２１２において生成されたＭＡＣとを含む更新フレームを生成してバスに送信する。
　次に、ＥＣＵ１１１は、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功したかどうかを判定する（Ｓ１２１４）。より具体的には、ＥＣＵ１１１は、ステップＳ１２１３において更新フレームをバスに送信後、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功したかどうかを、ＡＣＫスロットの値を見ることで判定する。
　ステップＳ１２１４において、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功したと判定した場合（Ｓ１２１４でＹ）、ＥＣＵ１１１は、一定時間待機後、再度更新処理を実施する（Ｓ１２１５）。つまり、ＥＣＵ１１１は、ＭＡＣ鍵の更新が失敗したのは軽微なエラーであったとしてステップＳ１２０１に戻り更新処理を再度行う。
　一方、ステップＳ１２１４において、更新フレームの受信に失敗したと判定した場合（Ｓ１２１４でＮ）、ＥＣＵ１１１は、致命的なエラー発生につき処理を中止する（Ｓ１２１６）。ＥＣＵ１１１は、ＭＡＣ鍵の更新が失敗したため、旧鍵に戻したことを確認するために送信した更新フレームの受信が失敗するのは、システム上致命的なエラーとみなせるからである。
　なお、更新処理を中止した場合には、ＥＣＵ１１１は、エラー発生について報知、ログの記録等の処理を実行しても良い。また、エラー発生の報知は、他のＥＣＵへのエラー発生を示すデータフレームの送信、ディスプレイ等への表示、音声出力、発光等により、実行され得る。
　図１７を用いて、全ＥＣＵの一であるＥＣＵ１１１が新たに生成したＭＡＣ鍵を配布することで新たなＭＡＣ鍵に更新する更新処理について説明したが、それに限らない。複数のＥＣＵのすべてが、所定状態である条件を満たした同一のタイミングで、ＭＡＣ鍵を用いて新たなＭＡＣ鍵を生成することにより、ＭＡＣ鍵を新たなＭＡＣ鍵に更新する更新処理を実行するとしてもよい。これについて図１８を用いて説明する。
　図１８は、図１５に示すステップＳ１２の詳細処理を示すフローチャートの別の一例である。図１８でも、図１７と同様に車載ネットワークシステム１００ａを構成する複数のＥＣＵの一であるＥＣＵ１１１が更新処理を実行する場合を例に挙げて説明する。図１７と同様の要素には同一の符号を付しており、詳細な説明は省略する。
　図１８では、まず、Ｓ１２１７Ａにおいて、ＥＣＵ１１１は、鍵更新のタイミングを示す通知フレームをブロードキャストする。より具体的には、ＥＣＵ１１１は、所定状態であるという鍵更新処理を実行する条件を満たしたタイミングを通知するために、鍵更新のタイミングを示す通知フレームをバスに送信する。鍵更新のタイミングを示す通知フレームとして、旧鍵である現在のＭＡＣ鍵をデータフィールドに含めて送るとしてもよいし、鍵更新のタイミングを示す旨をデータフィールドに含めて送るとしてもよい。これにより、自ＥＣＵ１１１を含む複数のＥＣＵすべてに同一タイミングでＭＡＣ鍵を更新させることができる。なお、上述したように、鍵更新処理を実行する条件を満たしたタイミングを通知することは必須ではない。ＣＡＮであれば複数のＥＣＵすべてがそれぞれ独立に鍵更新処理を実行する条件を満たしたタイミングを判定しても、同一のタイミングを判定できるので、複数のＥＣＵすべてが同一のタイミングで更新することができるからである。
　次に、ＥＣＵ１１１は、ステップＳ１２０１～Ｓ１２０５を行う。なお、鍵更新のタイミングを示す通知フレーム受信した他のＥＣＵは、ＥＣＵ１１１同様に、旧鍵であるＭＡＣ鍵と、リセット前のカウンタ値とをキャッシュしている。
　次に、ＥＣＵ１１１は、Ｓ１２０６Ａにおいて、更新の同期を確認するためのデータフレームである更新フレームをブロードキャストする。より具体的には、ＥＣＵ１１１は、メッセージＩＤとデータフィールド用のデータ値とステップＳ１２０５において生成したＭＡＣとを含む更新フレームを生成してバスへ送信する。
　次に、ＥＣＵ１１１は、ステップＳ１２０７Ａにおいて、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功したかどうかを判定する。
　ステップＳ１２０７Ａにおいて、自ＥＣＵ１１１を除く複数のＥＣＵすべてが更新フレームの受信に成功したと判定した場合（Ｓ１２０７ＡでＹ）、ＥＣＵ１１１は、キャッシュしていた旧鍵であるＭＡＣ鍵とリセット前のカウンタ値とを破棄して（Ｓ１２０８）、更新処理を終了する。
　一方、ステップＳ１２０７Ａにおいて、更新フレームの受信に成功しなかった場合（Ｓ１２０７ＡでＮ）、ＥＣＵ１１１は、キャッシュしておいた旧鍵であるＭＡＣ鍵を、再度ＭＡＣ鍵に設定し、キャッシュしておいたリセット前のカウンタ値を再度設定する（Ｓ１２１８）。
　なお、複数のＥＣＵは更新フレームの受信に成功したかどうかを、ＡＣＫスロットの値を見ることで判定できるので、ＥＣＵ１１１と同様に、複数のＥＣＵはステップＳ１２１８の処理を行う。
　次に、ＥＣＵ１１１は、一定時間待機後、再度更新処理を実施する（Ｓ１２１９）。つまり、ＥＣＵ１１１は、ＭＡＣ鍵の更新が失敗したのは軽微なエラーであったとしてステップＳ１２１７に戻り更新処理を再度行う。
　なお、どのＥＣＵが更新フレームを送信しても良い。本実施の形態では、例えば、メッセージＩＤ「１」のデータフレームを繰り返し送信するＥＣＵ１１１が、メッセージＩＤ「１」に対応するＭＡＣに係る更新処理を同期させるための更新フレームを送信するとして説明した。
　［１．７　実施の形態の効果］
　以上のように、本実施の形態によれば、ＭＡＣ鍵の鍵更新処理、および、カウンタのリセット処理を含む更新処理を、走行距離および／または車の状態に応じて実行することができる。これにより、更新処理を車両の動作に応じて適切な頻度で実行できる。
　より具体的には、本実施の形態によれば、車両の走行距離が閾値以下であるかを判定し、走行距離が短い、かつ、車の動作があるまたは予定されている場合に、更新処理をしないと判定することで、走行距離および／または車の状態に応じて更新処理を実行することができる。これにより、過度に更新処理が行われることを抑制できるので、ＣＡＮへの負荷を低減できる。つまり、ＥＣＵにおける鍵の更新処理が効率よく適切に実行され、車載ネットワークシステム全体として、安全な状態を維持することができる。
　［２．その他変形例］
　なお、本開示を上記実施の形態に基づいて説明してきたが、本開示は、上記実施の形態に限定されないのはもちろんである。以下のような場合も本開示に含まれる。
　（１）上記実施の形態では、フレームは定期的に送信されるとしたが、状態変化を通知するイベントとして送信されるとしてもよい。例えば、ドアロックの状態を定期的に送信するのではなく、ドアロックの状態が変化した場合にのみ、フレームを送信するとしても良い。また、定期的に送信、かつ、状態変化が発生した時に送信するとしても良い。
　（２）上記実施の形態では、フレームに含まれるＭＡＣのサイズは４バイトに制限するものではなく、送信毎に異なるサイズであってもよい。同様にカウンタサイズも１バイトに制限するものではない。
　また、フレームにデータ値、カウンタ値、ＭＡＣ値、データフレームに含まれるその他のフィールドの値全てが含まれている必要はなく、それぞれの組み合わせであっても良い。
　また、ＭＡＣサイズは固定のサイズに限定するものではなく、メッセージＩＤ毎に異なるサイズであってもよい。また、複数のメッセージにまたがって送信されるものであっても良い。
　（３）上記実施の形態では、カウンタ値を送信毎にインクリメントするとしているが、時刻に応じて自動的にインクリメントされる値であっても良い。また、時刻そのものの値をカウンタの代わりに使用してもよい。
　（４）上記実施の形態では、ＣＡＮプロトコルにおけるデータフレームを標準ＩＤフォーマットで記述しているが、拡張ＩＤフォーマットであっても良い。
　（５）上記実施の形態では、ＭＡＣ算出のアルゴリズムをＨＭＡＣとしているが、これに限らない。ＣＢＣ－ＭＡＣ、ＣＭＡＣであっても良い。また、ＭＡＣ計算に登場するパディングについては、ゼロパディング、ＩＳＯ１０１２６、ＰＫＣＳ１、ＰＫＣＳ５、ＰＫＣＳ７、その他、データサイズが計算に必要となるパディングの方式であれば何でもよい。
　また４バイトへのサイズの変更方法についても、先頭、最後尾、中間、いずれをとっても良い。また、連続している４バイトでなくても、特定のルールに従って１ビットずつ収集して結合しても良い。
　（６）上記実施の形態では、更新処理として、ＭＡＣ鍵の更新処理と、カウンタリセットの処理を同時に行っているが、いずれか一方のみ行ってもよい。また、ＭＡＣ鍵の更新処理についても、新たにＭＡＣ鍵更新処理専用の鍵を埋め込んでも良い。
　（７）上記実施の形態では、ＭＡＣ鍵をメッセージＩＤ毎に１つ保持しているが、ＥＣＵ毎に１つであっても良い。また、全てのＥＣＵが共通のＭＡＣ鍵を保持していても良い。同一のバスにつながるＥＣＵは全て共通のＭＡＣ鍵を保持していても良い。
　（８）上記実施の形態では、カウンタ値をメッセージＩＤ毎に１つ保持しているが、ＥＣＵ毎に１つであっても良い。また、同一のバス上を流れる全てのフレームに対して共通のカウンタ値を使用しても良い。
　（９）上記実施の形態では、カウンタ値はＭＡＣ算出のために使用しているが、データフィールドに含めて送信しても良い。また、その際は、全てのカウンタ値を送信してもよいし、一部のみを送信してもよい。
　（１０）上記実施の形態では、判定ルールは一例に限定されるわけではなく、他の判定ルールであってもよいし、複数の判定ルールがあってもよい。また、判定ルールはＥＣＵにそれぞれ出荷時に設定されてもよいし、搭載される車体の出荷時に設定されてもよいし、部品として、あるいは、搭載される車体自体が販売される時に設定されてもよい。また、判定ルールは、外部との通信、各種メディア、または、各種診断ツールによって設定されてもよい。
　（１１）上記実施の形態では、ＥＣＵ間で送受信されるデータフレームに対して、受信したＥＣＵがＭＡＣの検証を行っているが、全てのデータフレームに付与するＭＡＣの検証を一手に行うＭＡＣ検証用のＥＣＵであってもよい。
　また、このＭＡＣ検証用ＥＣＵが全てのメッセージＩＤに対応するＭＡＣ鍵と、カウンタ値を保持していてもよい。また、このＭＡＣ検証用ＥＣＵがＭＡＣ検証の結果、エラーと判定した場合、その他のＥＣＵでの受信を防止するため、エラーフレームを送信してもよい。
　（１２）上記実施の形態では、走行距離が閾値より大きい場合に、すべてのＭＡＣ鍵に関して、鍵更新処理を行っているが、これに限定するわけではなく、走行距離に関するメッセージＩＤのＭＡＣ鍵のみを更新するとしてもよい。
　（１３）上記実施の形態では、走行距離が閾値より大きい場合に、すべてのＭＡＣ鍵に関して、鍵更新処理を行っているが、これに限定するわけではなく、走行距離に関するメッセージＩＤが送信されるバスのみのＭＡＣ鍵を更新するとしてもよい。
　（１４）上記実施の形態では、所定の時間が経過、または走行距離が閾値より大きい場合に、判定ルールに基づいて更新処理を行っているが、これに限定するわけではなく、カウンタ値が閾値より大きい場合に更新処理を実行するとしてもよい。このとき、カウンタ値が閾値より大きいメッセージＩＤに対応するＭＡＣ鍵のみを更新するとしてもよい。
　（１５）上記の実施の形態における各装置は、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ、ハードディスクユニット、ディスプレイユニット、キーボード、マウスなどから構成されるコンピュータシステムである。ＲＡＭまたはハードディスクユニットには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、各装置は、その機能を達成する。ここでコンピュータプログラムは、所定の機能を達成するために、コンピュータに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
　（１６）上記の実施の形態における各装置は、構成する構成要素の一部または全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしてもよい。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどを含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、システムＬＳＩは、その機能を達成する。
　また、上記の各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部またはすべてを含むように１チップ化されてもよい。
　また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路または汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）、ＬＳＩ内部の回路セルの接続または設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
　さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
　（１７）上記の各装置を構成する構成要素の一部または全部は、各装置に脱着可能なＩＣカードまたは単体のモジュールから構成されているとしてもよい。ＩＣカードまたはモジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭなどから構成されるコンピュータシステムである。ＩＣカードまたはモジュールは、上記の超多機能ＬＳＩを含むとしてもよい。マイクロプロセッサが、コンピュータプログラムにしたがって動作することにより、ＩＣカードまたはモジュールは、その機能を達成する。このＩＣカードまたはこのモジュールは、耐タンパ性を有するとしてもよい。
　（１８）本開示は、上記に示す方法であるとしてもよい。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしてもよいし、コンピュータプログラムからなるデジタル信号であるとしてもよい。
　また、本開示は、コンピュータプログラムまたはデジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリなどに記録したものとしてもよい。また、これらの記録媒体に記録されている前記デジタル信号であるとしてもよい。
　また、本開示は、コンピュータプログラムまたはデジタル信号を、電気通信回線、無線または有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしてもよい。
　また、本開示は、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記録しており、マイクロプロセッサは、コンピュータプログラムにしたがって動作するとしてもよい。
　また、プログラムまたはデジタル信号を記録媒体に記録して移送することにより、またはプログラムまたはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
　（１９）上記実施の形態および上記変形例をそれぞれ組み合わせるとしてもよい。
　本開示は、ＥＣＵにおけるＭＡＣ鍵の更新処理が特定のタイミングに集中することなく、確実に実行され、車載ネットワークシステム全体として、安全な状態を維持することができる。
　１０　鍵更新管理装置
　１１　取得部
　１２，１２ａ　鍵更新部
　１３，１３ａ　鍵更新処理判定部
　１００，１００ａ　車載ネットワークシステム
　１０１　ゲートウェイ
　１１１，１２１，１３１，１４１，１５１，１６１，１７１，１８１，１８２，１８４，１８６，１９１　ＥＣＵ
　１１０　エンジン
　１２０　トランスミッション
　１３０　ブレーキ
　１４０　ステアリング
　１５０　自動ブレーキ
　１６０　車線維持装置
　１７０　車車間通信装置
　１８０　ヘッドユニット
　１８３　ウィンドウ開閉センサ
　１８５　ドア開閉センサ
　１８７　ＧＰＳセンサ
　１９０　ＩＴＳ装置
　１１１１　フレーム送受信部
　１１１２　フレーム解釈部
　１１１３　受信ＩＤ判断部
　１１１４　受信ＩＤリスト保持部
　１１１５　フレーム処理部
　１１１６　車体状態保持部
　１１１７　判定ルール保持部
　１１１８　タイマー
　１１１９　鍵更新判定部
　１１２０　更新処理部
　１１２１　ＭＡＣ鍵保持部
　１１２２　カウンタ保持部
　１１２３　ＭＡＣ生成部
　１１２４　フレーム生成部
　１１２５　データ取得部

Claims (13)

  1. 　複数の電子制御ユニットを有し、車両に搭載される車載ネットワークシステムにおいて用いられる鍵の更新処理方法であって、
    　前記複数の電子制御ユニットの少なくとも一つから送信される、前記車両の走行に関する情報である走行情報を取得する取得ステップと、
    　前記走行情報により得られる前記車両の走行に関する状態が所定状態であることを条件として、前記車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コードであって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵（ＭＡＣ：Message Authentication Code）を更新する鍵更新ステップとを含む、
    　更新処理方法。
  2. 　前記所定状態は、前記走行情報により得られる前記車両の走行距離であって前記ＭＡＣ鍵の前回の更新時からの前記車両の走行距離が閾値を超えた状態である、
    　請求項１に記載の更新処理方法。
  3. 　前記所定状態は、前記ＭＡＣ鍵の前回の更新時から所定時間経過後、かつ、前記走行情報により得られる前記車両の状態が駐車中である状態である、
    　請求項１に記載の更新処理方法。
  4. 　前記鍵更新ステップでは、
    　前記複数の電子制御ユニットのすべてが、前記条件を満たした同一のタイミングで、前記ＭＡＣ鍵を用いて新たなＭＡＣ鍵を生成することにより、前記ＭＡＣ鍵を前記新たなＭＡＣ鍵に更新する、
    　請求項１～３のいずれか１項に記載の更新処理方法。
  5. 　前記鍵更新ステップでは、
    　前記複数の電子制御ユニットの一が、前記条件を満たしたときに、前記ＭＡＣ鍵を用いて新たなＭＡＣ鍵を生成する生成ステップと、
    　前記一の電子制御ユニットが生成した前記新たなＭＡＣ鍵を、前記一の電子制御ユニット以外の前記複数の電子制御ユニットのすべてに配布することにより、前記ＭＡＣ鍵を前記新たなＭＡＣ鍵に更新する配布ステップとを含む、
    　請求項１～３のいずれか１項に記載の更新処理方法。
  6. 　前記車載ネットワークは、前記複数の電子制御ユニットがバスに接続されたＣＡＮ（Controller Area Network）であり、
    　前記更新処理方法は、
    　前記複数の電子制御ユニットのうちの一である第１電子制御ユニットが、ＣＡＮプロトコルに従ってバスを介して、前記データとしてデータフレーム、および、前記データに付加されるメッセージ認証コードとして前記データフレームのデータフィールドを前記メッセージ認証コードとした検証用データフレームの送信を行う送信ステップと、
    　前記複数の電子制御ユニットのうちの前記第１電子制御ユニット以外の複数の電子制御ユニットの少なくとも一である第２電子制御ユニットが、前記第１電子制御ユニットにより送信されたデータフレーム、および、検証用データフレームを、バスを介して受信する受信ステップとを含む、
    　請求項１～５のいずれか１項に記載の更新処理方法。
  7. 　前記送信ステップでは、
    　前記第１電子制御ユニットが、前記データフレームを識別するためのＩＤと送信カウンタによりカウントされたデータフレームの送信回数とを少なくとも結合した値に対して前記ＭＡＣ鍵を用いて前記メッセージ認証コードを生成するＭＡＣ生成ステップを含み、
    　前記受信ステップでは、
    　前記第２電子制御ユニットが、前記検証用データフレームを受信して得た前記メッセージ認証コードと、受信した前記データフレームに対応するＩＤと、受信カウンタによりカウントされたデータの受信回数とを少なくとも結合した値に対して、前記ＭＡＣ鍵を用いて生成したメッセージ認証コードとの同一性を検証する検証ステップを含む、
    　請求項６に記載の更新処理方法。
  8. 　前記車載ネットワークシステムは、前記複数の電子制御ユニットがＬＡＮ（Local Area Network）により接続されたネットワークであり、
    　前記更新処理方法は、
    　前記複数の電子制御ユニットのうちの一である第１電子制御ユニットが、前記データに付加される前記メッセージ認証コードとしてペイロード部分に前記メッセージ認証コードを含めて、前記データの送信を行う送信ステップと、
    　前記複数の電子制御ユニットのうちの前記第１電子制御ユニット以外の複数の電子制御ユニットの少なくとも一である第２電子制御ユニットが、前記第１電子制御ユニットにより送信された前記データを受信する受信ステップとを含む、
    　請求項１～５のいずれか１項に記載の更新処理方法。
  9. 　前記送信ステップでは、さらに、
    　前記第１電子制御ユニットが、前記データに付加された送信元アドレスおよび送信先アドレスと送信カウンタによりカウントされたデータの送信回数とを少なくとも結合した値に対して前記ＭＡＣ鍵を用いて前記メッセージ認証コードを生成するＭＡＣ生成ステップを含み、
    　前記受信ステップでは、
    　前記第２電子制御ユニットが、ペイロード部分に前記メッセージ認証コードが含まれた前記データを受信して得た前記メッセージ認証コードと、受信した当該データに付加された送信元アドレスおよぎ送信先アドレスと受信カウンタによりカウントされたデータの受信回数とを少なくとも結合した値に対して、前記ＭＡＣ鍵を用いて生成したメッセージ認証コードとの同一性を検証する検証ステップを含む、
    　請求項８に記載の更新処理方法。
  10. 　前記更新処理方法は、さらに、
    　前記条件として前記送信カウンタおよび前記受信カウンタをリセットするリセットステップを含む、
    　請求項９に記載の更新処理方法。
  11. 　前記複数の電子制御ユニットは、前記車両の制御用途により分類された複数のグループの一に属し、
    　前記複数のグループのそれぞれにおける前記所定状態は、前記複数のグループごとに定められる、
    　請求項１～１０のいずれか１項に記載の更新処理方法。
  12. 　複数の電子制御ユニットを有し、車両に搭載される車載ネットワークシステムであって、
    　前記複数の電子制御ユニットの少なくとも一つから送信される前記車両の走行に関する情報である走行情報を取得する取得部と、
    　前記走行情報により得られる前記車両の走行に関する状態が所定状態であることを条件として、前記車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コードであって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵（ＭＡＣ：Message Authentication Code）を更新する更新処理部とを備える、
    　車載ネットワークシステム。
  13. 　車両に搭載される車載ネットワークシステムに接続される電子制御ユニットであって、
    　ＣＰＵとメモリとを有し、
    　前記ＣＰＵは、複数の電子制御ユニットの少なくとも一つから送信される前記車両の走行に関する情報である走行情報を取得して前記メモリに格納し、
    　前記ＣＰＵは、
    　前記メモリに格納された前記走行情報により得られる前記車両の走行に関する状態が所定状態であることを条件として、前記車載ネットワークシステムにおいて授受されるデータに付加されるメッセージ認証コードであって改ざん防止のコードであるメッセージ認証コードの生成に利用される鍵であるＭＡＣ鍵（ＭＡＣ：Message Authentication Code）を更新する、
    　電子制御ユニット。
PCT/JP2018/006140 2017-03-21 2018-02-21 更新処理方法、車載ネットワークシステムおよび電子制御ユニット WO2018173603A1 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
JP2017-054953 2017-03-21
JP2017054953 2017-03-21
JP2018-006869 2018-01-19
JP2018006869A JP2018160888A (ja) 2017-03-21 2018-01-19 更新処理方法、車載ネットワークシステムおよび電子制御ユニット

Publications (1)

Publication Number Publication Date
WO2018173603A1 true WO2018173603A1 (ja) 2018-09-27

Family

ID=63584342

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2018/006140 WO2018173603A1 (ja) 2017-03-21 2018-02-21 更新処理方法、車載ネットワークシステムおよび電子制御ユニット

Country Status (1)

Country Link
WO (1) WO2018173603A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2021038684A1 (ja) * 2019-08-26 2021-03-04
CN113542428A (zh) * 2021-07-29 2021-10-22 中国第一汽车股份有限公司 车辆数据上传方法、装置、车辆、系统及存储介质
CN116319146A (zh) * 2023-02-01 2023-06-23 南京航空航天大学 车载can网络报文的功能管理的实现方法和存储介质
CN117714055A (zh) * 2024-02-05 2024-03-15 合肥工业大学 一种基于身份信息的车内网络通信方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007135107A (ja) * 2005-11-11 2007-05-31 Auto Network Gijutsu Kenkyusho:Kk 中継接続ユニット
WO2013140455A1 (ja) * 2012-03-22 2013-09-26 富士通株式会社 アドホックネットワークシステム、ノード、および通信方法
WO2015017045A1 (en) * 2013-07-03 2015-02-05 Keclon Sa Modified bacillus cereus phospholipase c protein and method of processing vegetable oil
WO2016006150A1 (ja) * 2014-07-10 2016-01-14 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 車載ネットワークシステム、電子制御ユニット、受信方法及び送信方法
JP2017038143A (ja) * 2015-08-07 2017-02-16 株式会社デンソー 通信システム、送信ノード、及び受信ノード
WO2017033602A1 (ja) * 2015-08-24 2017-03-02 Kddi株式会社 車載コンピュータシステム、車両、管理方法、及びコンピュータプログラム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007135107A (ja) * 2005-11-11 2007-05-31 Auto Network Gijutsu Kenkyusho:Kk 中継接続ユニット
WO2013140455A1 (ja) * 2012-03-22 2013-09-26 富士通株式会社 アドホックネットワークシステム、ノード、および通信方法
WO2015017045A1 (en) * 2013-07-03 2015-02-05 Keclon Sa Modified bacillus cereus phospholipase c protein and method of processing vegetable oil
WO2016006150A1 (ja) * 2014-07-10 2016-01-14 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 車載ネットワークシステム、電子制御ユニット、受信方法及び送信方法
JP2017038143A (ja) * 2015-08-07 2017-02-16 株式会社デンソー 通信システム、送信ノード、及び受信ノード
WO2017033602A1 (ja) * 2015-08-24 2017-03-02 Kddi株式会社 車載コンピュータシステム、車両、管理方法、及びコンピュータプログラム

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPWO2021038684A1 (ja) * 2019-08-26 2021-03-04
WO2021038684A1 (ja) * 2019-08-26 2021-03-04 日本電気株式会社 情報処理装置、ノード、データ記録方法及びコンピュータ可読媒体
JP7302664B2 (ja) 2019-08-26 2023-07-04 日本電気株式会社 情報処理装置、データ記録システム、データ記録方法及びプログラム
CN113542428A (zh) * 2021-07-29 2021-10-22 中国第一汽车股份有限公司 车辆数据上传方法、装置、车辆、系统及存储介质
CN116319146A (zh) * 2023-02-01 2023-06-23 南京航空航天大学 车载can网络报文的功能管理的实现方法和存储介质
CN117714055A (zh) * 2024-02-05 2024-03-15 合肥工业大学 一种基于身份信息的车内网络通信方法
CN117714055B (zh) * 2024-02-05 2024-04-12 合肥工业大学 一种基于身份信息的车内网络通信方法

Similar Documents

Publication Publication Date Title
JP7170780B2 (ja) 不正検知ルール更新方法、不正検知電子制御ユニット及び車載ネットワークシステム
CN107431625B (zh) 网关装置、车载网络系统以及转送方法
JP6407981B2 (ja) 車載ネットワークシステム、電子制御ユニット及び不正対処方法
JP6713415B2 (ja) 鍵管理方法、車載ネットワークシステム及び鍵管理装置
US10227053B2 (en) In-vehicle network system, electronic control unit, and update processing method
CN109076001B (zh) 帧传送阻止装置、帧传送阻止方法及车载网络系统
JP6807906B2 (ja) 車両へのコンピュータ攻撃を阻止するためのルールを生成するシステムおよび方法
JP2020013607A (ja) 不正対処方法及び路側機
JP6762347B2 (ja) 交通手段に対するコンピュータ攻撃を阻止するためのシステムおよび方法
WO2018173603A1 (ja) 更新処理方法、車載ネットワークシステムおよび電子制御ユニット
JP7412506B2 (ja) 不正検知ルール更新方法、不正検知電子制御ユニット及び車載ネットワークシステム
JP2018160888A (ja) 更新処理方法、車載ネットワークシステムおよび電子制御ユニット
JP6983977B2 (ja) ゲートウェイ装置、車載ネットワークシステム及び転送方法
JP7453404B2 (ja) 通信システム、中継装置、受信装置及び通信制御方法
WO2020105657A1 (ja) 車載中継装置及び中継方法
WO2018020833A1 (ja) フレーム伝送阻止装置、フレーム伝送阻止方法及び車載ネットワークシステム
JP7199467B2 (ja) 不正対処方法、および電子制御ユニット
CN111376848B (zh) 不正常检测规则更新方法、电子控制单元和车载网络系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18770828

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18770828

Country of ref document: EP

Kind code of ref document: A1