JP2020048203A - Update management method, update management device, and control program - Google Patents

Abstract

To provide an update management method for causing an external tool, capable of transmitting an update message to update data such as shared keys within ECUs making up an onboard network, to update shared keys and the like within the ECUs, while reducing the risk of all ECUs being unauthorizedly rewritten in a case where secret information given to the external tool is leaked.SOLUTION: An onboard network system 10 includes a master ECU that receives from an external tool 30 and verifies a public key certificate, update authority information indicating authority of the external tool. In a case that an update message instructing updating of shared keys or the like of one or multiple ECUs connected to a network has been transmitted from the external tool, if the verification of the update authority information is successful and the update authority information indicates that the transmission of the update message is within the range of authority of the external tool, the ECU transfers the update message to the network so that the ECUs update the shared keys or the like, and otherwise, the ECU does not transfer the update message in order to inhibit update by the ECUs.SELECTED DRAWING: Figure 1

Description

  The present invention relates to an update management method, an update management device, and the like for updating data held by an electronic control unit in a vehicle-mounted network system.

  2. Description of the Related Art In recent years, a number of devices called electronic control units (ECUs) are arranged in a system in an automobile. A network connecting these ECUs is called an in-vehicle network. There are many standards for in-vehicle networks. Among them, a standard called CAN (Controller Area Network) defined by ISO11898-1 is mainstream. In CAN, a communication path is composed of two buses, and an ECU connected to the bus is called a node. Each node connected to the bus sends and receives messages called frames. In the CAN, there is no identifier indicating the transmission destination or the transmission source, and the transmitting node transmits the frame with an ID (referred to as a message ID) for each frame (that is, sends a signal to the bus), and each receiving node is determined in advance. Only the received message ID is received (that is, a signal is read from the bus). In addition, a CSMA / CA (Carrier Sense Multiple Access / Collision Avoidance) method is adopted, and arbitration based on a message ID is performed at the time of simultaneous transmission of a plurality of nodes, and a frame having a small value of the message ID is transmitted preferentially. In addition, a port (hereinafter, referred to as a “diagnosis port”), which is an interface for communicating with an external tool (for example, an external device such as a failure diagnosis tool), which is called an OBD2 (On-Board Diagnostics 2), exists in the vehicle-mounted network. Used for ECU diagnosis. In recent years, not only diagnosis but also rewriting of ECU firmware using a diagnosis port has become possible. In addition, external tools that can be connected to the diagnostic port are on the market at a low price, and the number of external tools that can be used by general users rather than specialists is increasing.

  Thus, the risk of unauthorized external tools being connected to the diagnostic port is increasing. By illegally rewriting the firmware of the ECU in the in-vehicle network with an illegal external tool, it becomes possible to illegally control the vehicle body. As a method of preventing unauthorized rewriting of firmware via the diagnostic port, an identification code is embedded in a firmware update request message transmitted by an external tool, and when the identification code matches the registration code, the firmware is updated. There is a permission method (see Patent Document 1).

JP 2013-141948 A

  However, in the method of Patent Document 1, there is a risk that the firmware of all ECUs may be illegally rewritten when the identification code assigned to the external tool for updating the firmware is leaked.

  The present invention is directed to update management for reducing the risk that all ECU firmware is illegally rewritten when confidential information given to an external tool is leaked, and for allowing an external tool to update data in the ECU such as firmware. Provide a way. The present invention also provides an update management device for reducing the risk and allowing an external tool to update data in the ECU, and a control program for the update management device.

  According to one embodiment of the present invention, there is provided an update management method executed by an update management device in an in-vehicle network system, wherein the in-vehicle network system communicates via a network. Comprising a plurality of electronic control units, an external tool is connected, the update management device is one of the plurality of electronic units, the update management device and an electronic control unit other than the update management device, Holding a shared key used for transmitting a first session key for cryptographic processing during the period, and an expiration date of the shared key, and the update management method verifies update authority information indicating the authority of the external tool. Perform, the verification of the update authority information is successful, and, from the external tool, when receiving an update message instructing the update of the shared key, It is determined whether or not the transmission of the update message by the external tool is within the authority of the external tool. (I) The transmission of the update message by the external tool is within the authority of the external tool. When the update authority information indicates that the update authority information indicates, the update authority information is transferred to the network, and (ii) the update authority information indicates that transmission of the update message by the external tool is within the authority range of the external tool. When it is determined that does not indicate, suppress the transfer, determine whether the current time is within the expiration date, a certain time before the expiration date, or, if the expiration date has passed, the Send an alert message prompting you to update the shared key.

  According to another embodiment of the present invention, there is provided an update management device in an in-vehicle network system, wherein the in-vehicle network system includes a plurality of electronic control units performing communication via a network. An external tool is connected, the update management device is one of the plurality of electronic units, and encryption processing between the update management device and an electronic control unit other than the update management device is performed. A shared key used for transmitting a first session key for use, a holding unit for holding an expiration date of the shared key, update authority information indicating authority of the external tool from the external tool, and the shared key A receiving unit that receives an update message instructing the updating of the update unit, a verification unit that verifies the update authority information received by the receiving unit, When the verification by the authentication unit is successful and the update message is received by the receiving unit, (i) when the update authority information indicates that the transmission of the update message is within the authority range of the external tool, A transfer unit that transfers the update message to the network, and (ii) when the update authority information does not indicate that the transmission of the update message is within the authority range of the external tool, a transfer unit that inhibits the transfer; A determination unit that determines whether or not the expiration date is within, and a transmission unit that transmits an alert message urging the update of the shared key when a predetermined time before the expiration date, or when the expiration date has passed, Is provided.

  According to another embodiment of the present invention, there is provided a control program for controlling an update management device in an in-vehicle network system, wherein the in-vehicle network system communicates via a network. A plurality of electronic control units to perform, an external tool is connected, the update management device is one of the plurality of electronic control units, the electronic control unit, and other than the update management device and the update management device. Holding a shared key used for transmitting a first session key for encryption processing to and from an electronic control unit, and an expiration date of the shared key, wherein the control program has update authority information indicating authority of the external tool. And the verification of the update authority information succeeds, and the update from the external tool instructs the update of the shared key. When receiving the message, it is determined whether or not the transmission of the update message by the external tool is within the authority of the external tool. (I) The transmission of the update message by the external tool is performed by the external tool. When it is determined that the update authority information indicates that the update message is within the authority range, the update message is transferred to the network, and (ii) transmission of the update message by the external tool is within the authority range of the external tool. When it is determined that the update authority information does not indicate that the transfer is inhibited, the transfer is suppressed, and it is determined whether or not the current time is within the expiration date. If it has passed, an alert message prompting the update of the shared key is transmitted.

  An update management method according to one aspect of the present invention for solving the above problems includes an update management method used in an in-vehicle network system including a plurality of electronic control units that communicate via a bus and to which an external tool is connected. Receiving and verifying update authority information indicating the authority of the external tool, and when the external tool transmits an update message instructing to update data held by one or more electronic control units. In the above, when the verification is successful and the update authority information indicates that the transmission of the update message is within the authority range of the external tool, the one or more electronic controls correspond to the update message. When the update is executed by the unit and the verification fails, or when the transmission of the update message is performed by the authority of the external tool. When the update permission information does not indicate that it is the update management method for inhibiting the update corresponding to the update message by said one or more electronic control units.

  Further, in order to solve the above problem, an update management device according to one embodiment of the present invention is a single electronic control unit connected to a diagnostic port in an in-vehicle network system including a plurality of electronic control units performing communication via a bus. An update management device, wherein update authority information transmitted from the external tool connected to the diagnostic port via the diagnostic port and indicating the authority of the external tool, and one or more electronic control units A receiving unit that receives an update message instructing the update of the data held, a verification unit that verifies the update authority information received by the receiving unit, and a case where the update message is received by the receiving unit. The verification by the verification unit is successful, and the transmission of the update message is within the authority of the external tool. When the update authority information indicates, the update message is transferred to the bus, and when the verification by the verification unit fails, or when the transmission of the update message is within the authority range of the external tool, the update is performed. When the authority information is not indicated, the update management device includes a transfer unit that suppresses the transfer.

  Further, in order to solve the above-described problem, a control program according to one embodiment of the present invention provides a control program as one electronic control unit connected to a diagnostic port in a vehicle-mounted network system including a plurality of electronic control units communicating via a bus. A control program for causing an update management device having a processor to execute a predetermined update management process, wherein the update management process is transmitted from an external tool connected to the diagnostic port via the diagnostic port. An update authority information receiving step of receiving update authority information indicating the authority of the external tool, a verification step of verifying the update authority information received in the update authority information receiving step, and the diagnostic port from the external tool. Updates of data held by one or more of the electronic control units transmitted via Update message receiving step of receiving an update message to be indicated, and when the update message is received in the update message receiving step, the verification in the verification step is successful, and the transmission of the update message is performed by the external device. Transferring the update message to the bus when the update authority information indicates that the update authority information is within the authority range of the tool; and when the verification in the verification step fails, or when the transmission of the update message is performed by the external tool. A transfer control step of suppressing the transfer when the update right information does not indicate that the transfer is within the right range.

  ADVANTAGE OF THE INVENTION According to this invention, when the confidential information given to the external tool leaks, the risk of the firmware of all ECUs being rewritten illegally can be reduced and an external tool can update the data in ECU.

FIG. 1 is an overall configuration diagram of an in-vehicle network system according to a first embodiment. FIG. 3 is a diagram illustrating a format of a data frame defined by a CAN protocol. FIG. 2 is a diagram illustrating a key issuing system related to an ECU and an external tool. FIG. 3 is a diagram illustrating a configuration of a public key certificate. FIG. 7 is a diagram illustrating a correspondence relationship between a level of update authority information described in a public key certificate and a function type of an ECU. FIG. 3 is a diagram illustrating a shared key held by an ECU. FIG. 2 is a configuration diagram of a master ECU (update management device) according to the first embodiment. FIG. 5 is a diagram showing level information according to the first embodiment. FIG. 2 is a configuration diagram of an ECU. It is a figure showing a reception ID list. FIG. 13 is a diagram showing a shared key update sequence according to the first embodiment (continued from FIG. 12). FIG. 12 is a diagram illustrating a shared key update sequence according to the first embodiment (continued from FIG. 11). FIG. 7 is an overall configuration diagram of an in-vehicle network system according to a second embodiment. FIG. 14 is a diagram showing level information according to the second embodiment. FIG. 17 is a diagram illustrating a shared key update sequence according to the second embodiment (continued from FIG. 16). FIG. 16 is a diagram illustrating a shared key update sequence according to the second embodiment (continued from FIG. 15). FIG. 13 is a configuration diagram of a master ECU (update management device) according to a third embodiment. FIG. 17 is a diagram showing information in which a shared key and an expiration date and the like according to the third embodiment are associated with each other. FIG. 14 is a diagram showing an example of a screen for prompting the update of a shared key according to the third embodiment. FIG. 22 is a diagram illustrating a shared key update sequence according to Embodiment 4 (continued from FIG. 21). FIG. 21 illustrates a shared key update sequence according to Embodiment 4 (continued from FIG. 20). FIG. 14 is a diagram showing log information held by a server according to Embodiment 4.

  An update management method according to an aspect of the present invention is an update management method executed by an update management device in an in-vehicle network system, wherein the in-vehicle network system includes a plurality of electronic control units that communicate via a network. An external tool is connected, the update management device is one of the plurality of electronic units, and is used for encryption processing between the update management device and an electronic control unit other than the update management device. Holding a shared key used for transmitting the first session key and an expiration date of the shared key; the update management method verifies update authority information indicating authority of the external tool; If the verification is successful, and an update message instructing to update the shared key is received from the external tool, the external tool Determining whether the transmission of the new message is within the authority of the external tool; and (i) determining that the transmission of the update message by the external tool is within the authority of the external tool. Transfer the update message to the network, and (ii) determine that the update authority information does not indicate that the transmission of the update message by the external tool is within the authority range of the external tool. In this case, the transfer is suppressed and it is determined whether or not the current time is within the expiration date, and when the expiration date has passed, or when the expiration date has passed, the update of the shared key is performed. Send an alert message to prompt.

  Further, the plurality of electronic control units may communicate according to a Controller Area Network (CAN) protocol, and the external tool may transmit the update message according to a CAN protocol.

  Also, the determination as to whether the transmission of the update message from the external tool is within the authority range of the external tool is made based on the message ID of the update message. Performing the update on the electronic control unit defined to receive the update message having the message ID when it is determined that the update authority information indicates that the update authority information is within the authority range of the tool. It is good.

  The update authority information specifies one or more function types among the plurality of function types for classification of the electronic control unit, and is classified into one of the specified one or more function types. The function type of the electronic control unit, which indicates that the external tool has authority to cause the electronic control unit to perform the update, and is configured to receive the message ID based on the message ID of the update message. The determination may be made by determining whether or not one of the one or more function types specified by the update authority information matches.

  Further, the update authority information indicates one level among a plurality of levels for specifying one or a plurality of the function types, and a relatively high level is one or a plurality of levels specified by a relatively low level. A plurality of function types including a plurality of function types may be specified.

  Further, when the state of the vehicle equipped with the in-vehicle network system is not a predetermined state, the transfer of the update message to the network may be suppressed.

  Further, when a battery that supplies power to each electronic control unit in the in-vehicle network system does not have a predetermined remaining battery level, transfer of the update message to the network may be suppressed.

  Further, (i) identification information for identifying the in-vehicle network system among a plurality of in-vehicle network systems, and (ii) result information indicating a processing result of the update message may be transmitted to the external tool. .

  Further, the update of the data held by the electronic control unit indicated by the update message may be an update of the firmware of the electronic control unit.

  Further, the alert message may be transmitted to an electronic control unit that controls a display.

  According to another embodiment of the present invention, there is provided an update management device in an in-vehicle network system, wherein the in-vehicle network system includes a plurality of electronic control units performing communication via a network. An external tool is connected, the update management device is one of the plurality of electronic units, and encryption processing between the update management device and an electronic control unit other than the update management device is performed. A shared key used for transmitting a first session key for use, a holding unit for holding an expiration date of the shared key, update authority information indicating authority of the external tool from the external tool, and the shared key A receiving unit that receives an update message instructing the updating of the update unit, a verification unit that verifies the update authority information received by the receiving unit, When the verification by the authentication unit is successful and the update message is received by the receiving unit, (i) when the update authority information indicates that the transmission of the update message is within the authority range of the external tool, A transfer unit that transfers the update message to the network, and (ii) when the update authority information does not indicate that the transmission of the update message is within the authority range of the external tool, a transfer unit that inhibits the transfer; A determination unit that determines whether or not the expiration date is within, and a transmission unit that transmits an alert message urging the update of the shared key when a predetermined time before the expiration date, or when the expiration date has passed, Is provided.

  According to another embodiment of the present invention, there is provided a control program for controlling an update management device in an in-vehicle network system, wherein the in-vehicle network system communicates via a network. A plurality of electronic control units to perform, an external tool is connected, the update management device is one of the plurality of electronic control units, the electronic control unit, and other than the update management device and the update management device. Holding a shared key used for transmitting a first session key for encryption processing to and from an electronic control unit, and an expiration date of the shared key, wherein the control program has update authority information indicating authority of the external tool. And the verification of the update authority information succeeds, and the update from the external tool instructs the update of the shared key. When receiving the message, it is determined whether or not the transmission of the update message by the external tool is within the authority of the external tool. (I) The transmission of the update message by the external tool is performed by the external tool. When it is determined that the update authority information indicates that the update message is within the authority range, the update message is transferred to the network, and (ii) transmission of the update message by the external tool is within the authority range of the external tool. When it is determined that the update authority information does not indicate that the transfer is inhibited, the transfer is suppressed, and it is determined whether or not the current time is within the expiration date. If it has passed, an alert message prompting the update of the shared key is transmitted.

  An update management method according to an aspect of the present invention includes a plurality of electronic control units that perform communication via a bus, and is an update management method used in an in-vehicle network system to which an external tool is connected. Upon receiving and verifying the update authority information indicating the authority, when the external tool transmits an update message instructing to update data held by one or more electronic control units, the verification is successful. And, when the update authority information indicates that the transmission of the update message is within the authority range of the external tool, the update is executed by the one or more electronic control units in response to the update message. The update right when the verification fails or that the transmission of the update message is within the authority of the external tool. When the information is not shown, an update management method for inhibiting the update corresponding to the update message by said one or more electronic control units. Thus, the authority to transmit an update message instructing to update data in the ECU can be determined differently for each external tool based on the verifiable update authority information. Then, only the external tool having the authority to transmit the update message of the data in some ECUs in the vehicle-mounted network system can update the data in some ECUs. Further, even if confidential information is leaked about an external tool that has a right to transmit a data update message in some of the ECUs, ECUs other than some of the ECUs are not illegally rewritten. For this reason, the risk that the firmware etc. of all ECUs in the in-vehicle network are illegally rewritten can be reduced, and an external tool can update data in the ECU.

  Further, the plurality of electronic control units may perform communication via the bus according to a Controller Area Network (CAN) protocol, and the external tool may transmit the update message according to a CAN protocol. This allows an external tool having an appropriate authority to update data in the ECU in the in-vehicle network system according to CAN.

  Further, when the update message is transmitted from the external tool, whether the update authority information indicates that transmission of the update message is within the authority range of the external tool based on the message ID of the update message. It is determined to receive the update message having the message ID when it is determined that the update authority information indicates that the transmission of the update message is within the authority range of the external tool. The update may be executed by the electronic control unit. As a result, whether or not the ECU is the target of the update instruction in the update message is determined based on the CAN frame ID (message ID). For this reason, the authority to update one or more specific ECUs can be distinguished from the authority to update one or more other ECUs. The update can be permitted only for the appropriate external tools that the user has.

  The update authority information specifies one or more function types among the plurality of function types for classification of the electronic control unit, and is classified into one of the specified one or more function types. Indicates that the external tool has the authority to make the electronic control unit perform the update, and when the update message is transmitted from the external tool, receives the message ID based on the message ID of the update message. Performing the determination by determining whether or not the function type of the electronic control unit determined to be performed matches one or more of the one or more function types specified by the update authority information. It is good. As a result, it becomes possible to perform an operation in which the authority of the update is distinguished and the external tool is recognized as an external tool for each function type that classifies the ECUs in terms of functions. This recognition is performed, for example, by providing verifiable update authority information.

  Further, the update authority information indicates one level among a plurality of levels for specifying one or a plurality of the function types, and a relatively high level is one or a plurality of levels specified by a relatively low level. A plurality of function types including a plurality of function types may be specified. This makes it possible to make the level of update authority different for each external tool. For example, even if confidential information about an external tool having a low level of authority is leaked, an ECU other than a function type of an ECU that can be updated in accordance with the level (that is, an ECU that can be updated by an external tool with a high level of authority) ) Is not illegally rewritten.

  Also, the update management device, which is one of the electronic control units, receives the update authority information from the external tool connected to a diagnostic port connected to the update management device, performs the verification, and performs the verification from the external tool. When the update message is transmitted, the update message is received, and when the update message is received, the verification is successful, and the update authority information indicates that the transmission of the update message is within the authority range of the external tool. When the indicates, transfer the update message to the bus, when the verification fails, or when the update authority information does not indicate that the transmission of the update message is within the authority range of the external tool, The transfer may be suppressed. Thereby, since the update management device (master ECU) controls whether or not to transfer the update message to another ECU, the other ECU may omit the inspection related to the authority of the external tool.

  Further, if the update message has not been subjected to the predetermined encryption process using a session key, the update by the electronic control unit corresponding to the update message is suppressed, and the update management device receives the update authority information. The update authority information is described, by performing the reception of a public key certificate related to the public key of the external tool, if the verification is successful, the external tool transmits the update message The session key used to perform the predetermined encryption processing may be encrypted with the public key of the external tool and transmitted to the external tool. As a result, the authority to update the external tool can be certified by issuing a public key certificate. In addition, it is possible to use the public key in the public key certificate to ensure the security of the communication contents of the external tool.

  Further, the update management device, when the update message is transmitted from the external tool, suppresses transfer of the update message to the bus when a state of the vehicle equipped with the in-vehicle network system is not a predetermined state. It is good. With this, if a predetermined state, for example, a stopped state, a state in which the engine is stopped, or the like is determined, data in the ECU is updated, for example, in a stopped state in which the load on the ECU related to traveling is reduced and bus traffic is relatively small. Therefore, for example, it is possible to reduce a possibility that a problem occurs in updating.

  Further, the update management device, when the update message is transmitted from the external tool, when the battery that supplies power to each electronic control unit in the in-vehicle network system does not have a predetermined battery remaining amount, the update management device The transfer of the message to the bus may be suppressed. Thus, if the predetermined battery remaining amount is set to a sufficient amount, for example, such that the remaining amount of the battery is sufficient for updating, it is possible to prevent a problem due to running out of the battery during updating.

  Further, the electronic control unit other than the update management device and the update management device hold a shared key shared between them for use in transmitting a session key for encryption processing related to communication contents, and the update message is The instructed update of the data held by the electronic control unit may be an update of the shared key. As a result, the shared key shared between the master ECU and the other ECUs can be updated by the external tool.

  Further, warning information for urging the renewal of the shared key may be output a predetermined period before the expiration date of the shared key. Thus, key update can be prompted before the expiration date of the shared key expires, and the risk that the shared key can continue to be used after the expiration date can be reduced.

  Further, the update management device may transmit, to the external tool, identification information for identifying the in-vehicle network system among a plurality of in-vehicle network systems and result information indicating a processing result of the update message. This makes it possible for the external tool to manage the result of updating data in the ECU for each vehicle (that is, for each vehicle-mounted network system).

  Further, the external tool may transmit the result information and the identification information to a server. This makes it possible for the server to manage the result of updating the data in the ECU for each vehicle.

  Further, the update of the data held by the electronic control unit indicated by the update message may be an update of the firmware of the electronic control unit. Thus, the authority for updating the firmware of the ECU can be flexibly set for each external tool.

  Further, the update management device according to one aspect of the present invention is an update management device which is one electronic control unit connected to a diagnostic port in a vehicle-mounted network system including a plurality of electronic control units communicating via a bus. Updating authority information transmitted from the external tool connected to the diagnostic port via the diagnostic port and indicating the authority of the external tool, and updating of data held by one or more of the electronic control units. A receiving unit that receives the instructed update message, a verification unit that verifies the update authority information received by the reception unit, and, when the update message is received by the reception unit, the verification by the verification unit. Is successful and the update authority information indicates that the transmission of the update message is within the authority range of the external tool. Transfer the update message to the bus, and when the verification by the verification unit fails, or when the update authority information indicates that the transmission of the update message is within the authority range of the external tool. If not, the update management device includes a transfer unit that suppresses the transfer. Thus, when the confidential information given to the external tool is leaked, the risk that the firmware and the like in all ECUs are illegally rewritten is reduced, and the external tool can update the data in the ECU.

  Further, a control program according to an aspect of the present invention provides an update management device having a processor as one electronic control unit connected to a diagnostic port in a vehicle-mounted network system including a plurality of electronic control units communicating via a bus. A control program for causing a predetermined update management process to be executed, wherein the update management process is executed by the external tool connected to the diagnostic port and transmitted through the diagnostic port. An update right information receiving step of receiving update right information indicating the update right information, a verification step of verifying the update right information received in the update right information receiving step, and an update request transmitted from the external tool via the diagnostic port. An update message instructing an update of data held by one or more of the electronic control units. Update message receiving step, and when the update message is received in the update message receiving step, the verification in the verification step is successful, and the transmission of the update message is within the authority of the external tool. When the update authority information indicates that the update message is transferred to the bus, and the verification in the verification step fails, or the transmission of the update message is within the authority range of the external tool. A transfer control step of suppressing the transfer when the update authority information does not indicate that the update right information is present. By installing this program in the update management device and causing the processor to execute the program, the risk of unauthorized rewriting of firmware and the like in all ECUs when confidential information given to an external tool is leaked is reduced. This allows the tool to update data in the ECU.

  Note that these general or specific aspects may be realized by a system, a method, an integrated circuit, a computer program or a computer-readable recording medium such as a CD-ROM, and the system, the method, the integrated circuit, and the computer. It may be realized by an arbitrary combination of a program or a recording medium.

  Hereinafter, an in-vehicle network system using the update management method according to the embodiment will be described with reference to the drawings. Each of the embodiments shown here is a specific example of the present invention. Therefore, the numerical values, constituent elements, arrangement and connection forms of the constituent elements, steps (processes), order of steps, and the like shown in the following embodiments are merely examples and do not limit the present invention. Among the components in the following embodiments, components not described in the independent claims are components that can be arbitrarily added. In addition, each drawing is a schematic diagram, and is not necessarily strictly illustrated.

(Embodiment 1)
Hereinafter, as an embodiment of the present invention, an update management method used in an in-vehicle network system 10 in which a plurality of ECUs including a master ECU 100 as an update management device communicate via a bus will be described with reference to the drawings.

  As an update management method, in the present embodiment, the master ECU 100 authenticates the external tool 30 when the external tool is connected to the diagnostic port of the in-vehicle network system 10 and authenticates the external tool 30 only when certain conditions are satisfied. Shows an example in which updating of ECU data (firmware and the like) is permitted.

[1.1 Overall Configuration of In-Vehicle Network System 10]
FIG. 1 is a diagram illustrating an overall configuration of an in-vehicle network system 10 according to the first embodiment. FIG. 2 shows an external tool 30 in addition to the in-vehicle network system 10. The external tools 30 are representatively representative of various external tools (for example, external tools 30a and 30b to be described later) manufactured by, for example, a company that manufactures and maintains various ECUs. The in-vehicle network system 10 is an example of a network communication system that communicates according to a CAN protocol, and is a network communication system in an automobile (vehicle) on which various devices such as a control device and a sensor are mounted. The in-vehicle network system 10 includes a plurality of devices (nodes) that perform frame-related communication via a bus according to a CAN protocol, and uses an update management method. Specifically, as shown in FIG. 1, the in-vehicle network system 10 includes a diagnostic port 600, buses 500a to 500d, a master ECU (update management device) 100, a head unit 200, a gateway 300, and an ECU 400a connected to various devices. And each node connected to a bus such as an ECU of 400 f. Although the in-vehicle network system 10 may include any number of ECUs in addition to the master ECU 100 and the ECUs 400a to 400f, the following description focuses on the master ECU 100 and the ECUs 400a to 400f for convenience. The ECU is, for example, a device including a processor (microprocessor), a digital circuit such as a memory, an analog circuit, a communication circuit, and the like. The memory is a ROM, a RAM, or the like, and can store a control program (computer program) executed by the processor. For example, when the processor operates according to the control program, the ECU realizes various functions. Note that the computer program is configured by combining a plurality of instruction codes indicating instructions to the processor in order to achieve a predetermined function.

  The diagnostic port 600 is a port for connecting the external tool 30 when performing maintenance of the ECU configuring the in-vehicle network system 10, and is connected to the master ECU 100 by a bus 500d. The diagnostic port 600 is, for example, a connector compliant with OBD2. The external tool 30 can transmit a frame according to the CAN protocol to the in-vehicle network system 10 by connecting to the diagnostic port 600. For example, the external tool 30 transmits a message including a message ID in a predetermined range predetermined in the in-vehicle network system 10, such as an update message for updating firmware of the ECU or a message for diagnosis for failure diagnosis of the ECU. Can send. Here, in particular, it is noted that the external tool transmits an update message (that is, an update request frame) including a predetermined range of message IDs for updating each of the ECU firmware and the shared key. Will be explained.

  The master ECU 100 authenticates the external tool 30, and permits updating of an update message from the external tool based on the update authority information described in a certificate of the external tool 30 (a public key certificate described later). This is a kind of ECU as an update management device having a role of making a determination as to whether or not the update is performed. The master ECU 100 is used to transmit a session key for encryption processing related to communication contents in a frame between each of one or more ECUs other than the own ECU among the plurality of ECUs in the in-vehicle network system 10. It has a function of holding the same shared key shared in advance and transmitting the session key to each ECU.

  The ECUs 400a to 400f are connected to any of the buses 500a to 500c, and are connected to the engine 310, the brake 320, the door open / close sensor 330, the window open / close sensor 340, the airbag 350, and the head unit 200, respectively. Each of the ECUs 400a to 400e acquires the state of a connected device (the engine 310 and the like) and periodically transmits a frame representing the state to a network (that is, a bus). The head unit 200 includes, for example, a display device such as a liquid crystal display (LCD) provided on an instrument panel (instrument panel) of an automobile or the like, and can notify a driver of the vehicle. The ECU 400f connected to the head unit 200 has a function of receiving a frame from the bus 500c and displaying various states represented by the frame on a display device of the head unit 200.

  The gateway 300 is connected to a bus 500a connected to the ECU 400a and the ECU 400b, a bus 500b connected to the master ECU 100 and the ECUs 400c to 400e, and a bus 500c connected to the ECU 400f, and transfers a frame received from each bus to another bus. It has a function to do. It is also possible to switch whether the received frame is transferred or not for each connected bus. Gateway 300 is a kind of ECU.

  In the in-vehicle network system 10, each ECU including the master ECU 400 exchanges frames via the bus according to the CAN protocol. Frames in the CAN protocol include a data frame, a remote frame, an overload frame, and an error frame, but for convenience of explanation, the description will focus on the data frame.

[1.2 Data frame format]
Hereinafter, a data frame which is one of frames used in a network according to the CAN protocol will be described.

  FIG. 2 is a diagram showing a format of a data frame defined by the CAN protocol. FIG. 1 shows a data frame in a standard ID format defined by the CAN protocol. The data frame includes an SOF (Start Of Frame), an ID field, an RTR (Remote Transmission Request), an IDE (Identifier Extension), a reserved bit “r”, a DLC (Data Length Code), a data field, and a CRC (Cyclic Redundancy Check) sequence. , CRC delimiter “DEL”, ACK (Acknowledgement) slot, ACK delimiter “DEL”, and EOF (End Of Frame) fields.

  The SOF is composed of a 1-bit dominant. The idle state of the bus is recessive, and the start of frame transmission is notified by changing to dominant by SOF.

  The ID field is a field configured of 11 bits and storing an ID (that is, a message ID) that is a value indicating a type of data. When a plurality of nodes start transmission at the same time, in order to perform communication arbitration in this ID field, a frame having a small ID has a higher priority.

  RTR is a value for distinguishing between a data frame and a remote frame, and a data frame is composed of one dominant bit.

  IDE and “r” are both composed of one dominant bit.

  DLC is composed of 4 bits and is a value indicating the length of the data field. In addition, IDE, "r", and DLC are collectively called a control field.

  The data field is a value indicating the content of data to be transmitted, which is composed of a maximum of 64 bits. The length can be adjusted every 8 bits. The specification of the data to be transmitted is not defined by the CAN protocol, but is defined by the vehicle-mounted network system 10. Therefore, the specifications depend on the vehicle type, the manufacturer (manufacturer), and the like.

  The CRC sequence is composed of 15 bits. It is calculated from the transmission values of the SOF, ID field, control field and data field.

  The CRC delimiter is a delimiter indicating the end of a CRC sequence composed of 1-bit recessive. Note that the CRC sequence and the CRC delimiter are collectively referred to as a CRC field.

  The ACK slot is composed of one bit. The transmitting node performs transmission by making the ACK slot recessive. The receiving node transmits the ACK slot as a dominant if the reception has been normally performed up to the CRC sequence. Since dominant is given priority over recessive, if the ACK slot is dominant after transmission, the transmitting node can confirm that any of the receiving nodes has successfully received.

  The ACK delimiter is a delimiter that indicates the end of the ACK composed of 1-bit recessive.

  The EOF is composed of 7-bit recessive and indicates the end of a data frame.

[1.3 Key issuing system]
FIG. 3 is a diagram showing a key issuing system related to the ECU and the external tool described above. The key issuing organization 20 distributes the public key certificates 40a to 40c, the secret keys 50a to 50c, and the shared key 60 to the maker 21. The distributed keys and certificates are written by the manufacturer 21 in the external tools 30a and 30b, the master ECU 100, and the ECUs 400a to 400f at the manufacturing stage or the like. The maker 21 is, for example, an OEM maker (Original Equipment Manufacturer), an ECU vendor, or the like. The public key certificate describing the public key and the private key are used in a public key infrastructure (PKI), and the public key and the private key are key pairs such as elliptical encryption and RSA encryption. The secret key and the public key certificate are used for authentication between the master ECU 100 and the external tools 30a and 30b. The shared key 60 represents each shared key as a representative. The shared key 60 is an AES (Advanced Encryption Standard) key of a common key cryptosystem, is shared between the master ECU 100 and each of the other ECUs, and is used for transmitting a session key for encryption processing related to the frame. . As the encryption processing related to the frame, in addition to encryption and decryption of the content of the data field of the frame, for example, a message authentication code (MAC) is generated in the data field of the frame on the transmission side of the frame. Then, the receiving side verifies the MAC. This MAC enables detection of data tampering. The session key is used for generating a MAC, for example.

  In the example of FIG. 3, the public key certificate 40a and the secret key 50a are written in the external tool 30a, the public key certificate 40b and the secret key 50b are written in the external tool 30b, and the master ECU 20 The public key certificate 40c, the secret key 50c, and the shared key 60 are written, indicating that the ECU 400a to 400f writes the shared key 60. In the example of FIG. 3, the level of the update authority information described in the public key certificate 40a is 3, and the level of the update authority information described in the public key certificate 40b is 4.

[1.4 Public key certificate]
FIG. 4 is a diagram showing an example of the configuration of a public key certificate 40a issued or distributed by the key issuing organization 20 to be written into the external tools 30a and 30b. The public key certificate 40b has a similar configuration.

  As shown in the figure, the public key certificate includes a version, an issuer, start and end of a validity period, certificate identification information (ID), public key, update authority information (level), and a signature for these. Be composed. The signature is given by the key issuing organization 20 or a certificate authority such as a portal server. For this reason, the master ECU 100 can authenticate the external tool 30 by acquiring a public key certificate from the external tool 30 and verifying the signature.

  According to the update authority information in the public key certificate, the authority to transmit an update message instructing the external tool 30 (the external tools 30a, 30b, etc.) to update the data in the ECU for which type of ECU is recognized. Information, specifically, one of the levels of authority divided into a plurality of levels. Therefore, the updated authority information indicates the authority level of the external tool 30 that has been authorized by the signing authority or the like.

  The public key certificate 40c written in master ECU 100 includes each element other than the update authority information in the configuration example shown in FIG.

[1.5 Update authority information]
FIG. 5 shows an example of the correspondence between the level (that is, the authority level) of the update authority information described in the public key certificate of FIG. 3 and a plurality of function types for classifying ECU functions. FIG.

  First, the function types of the ECU will be described. The drive system function is a function related to running of the vehicle, such as control of an engine, a motor, a fuel, a battery, a transmission, and the like. For example, the ECU 400a related to the engine 310 corresponds to the function type of the drive system function. The chassis-related functions are functions related to control of vehicle behavior such as "turning" and "stopping" of brakes and steering. The function type of the chassis-related function corresponds to, for example, the ECU 400b related to the brake 320. The body function is a function related to control of vehicle equipment such as a door lock, an air conditioner, a light, and a turn signal. For example, the ECU 400c related to the door opening / closing sensor 330 and the ECU 400d related to the window opening / closing sensor 340 correspond to the function type of the body system function. The safety and comfort function is a function for automatically realizing safe and comfortable driving, such as an automatic brake, a lane keeping function, an inter-vehicle distance keeping function, a collision prevention function, and an airbag. The ECU 400e related to the airbag 350 corresponds to the function type of the safety and comfort function. The ITS (Intelligent Transport Systems) system function is a function corresponding to an intelligent transportation system such as an ETC (Electronic Toll Collection System). The telematics function is a function corresponding to a service using mobile communication. The infotainment function is an entertainment function related to car navigation, audio, and the like. The function type of the infotainment function corresponds to, for example, the ECU 400f relating to the head unit 200.

  The authority level as the content of the update authority information, which is authorized by the certificate authority or the like that is the signer of the public key certificate, is one of the above-described plurality of function types based on the correspondence relationship illustrated in FIG. Alternatively, a plurality of function types are specified. Then, the external tool provided with the public key certificate sends data (firmware, shared data) in the ECU to an ECU classified into one of the one or more function types specified by the level of the update authority information. Key) is authorized to be updated, that is, it is authorized to transmit an update message for updating the firmware or the shared key.

  According to the example of FIG. 5, a public key certificate describing update authority information indicating any one of four levels of update authority from the highest level 4 to the lowest level 1 is given to each external tool. (That is, written). Individual external tools may differ in function, configuration, and the like. For this reason, for example, the function type of the ECU to be handled by the external tool, the confidentiality and reliability of the external tool, the reliability of the manufacturer of the external tool, and other various circumstances are taken into consideration for each external tool. Update authority information can be defined. Note that FIG. 5 merely shows an example of the level, and the number of levels, the correspondence between the level and the function type, and the like may be determined differently from this example. Further, a correspondence may be determined such that each of a plurality of levels (for example, level 4 and level 2) corresponds to the same one function type. Also, the classification of the function type may be determined differently from the example of FIG. Here, a relatively higher level in the update authority information specifies a plurality of function types including one or more function types specified by lower levels, that is, a higher level includes a lower level authority. It will be described as what is done. However, the correspondence between the level and the function type may be determined so that there is no inclusion of the authority between the authority levels. However, when the level of authority authorized for the external tool is relatively low, only the updating of data in some ECUs that are not related to the running, behavior, etc. of the vehicle is permitted, and ECUs other than those are permitted. It is useful not to let the data in the inside be updated. Specifically, if the level of the authority granted to the external tool (that is, the level that is the content of the update authority information) is 3, the external tool performs all levels below level 3 (that is, level 1 to level 3). ) It is permitted to transmit an update message to each ECU classified into the corresponding function type to execute the update of the data in the ECU.

  When the external tool 30 is connected to the diagnostic port 600, the master ECU 100 in the in-vehicle network system 10 receives update authority information that determines the authority level from the external tool 30, and based on the update authority information, A determination is made as to whether or not the update is permitted for the update message transmitted by 30. In this determination, master ECU 100 refers to level information 1040 determined based on the above-described correspondence between levels and function types (see FIG. 5). The level information 1040 will be described later with reference to FIG.

[1.6 Shared key]
FIG. 6 is a diagram showing a shared key held by master ECU 100 and ECUs 400a to 400f. Specifically, the shared key 60 described above includes a shared key 60a shared by all ECUs, a shared key 60b shared by the ECU 400f and the master ECU 100, ECUs 400c and 400d, and the master ECU 100, as shown in FIG. , A shared key 60d shared by the ECUs 400a and 400b and the master ECU 100, and a shared key 60e shared by the ECU 400e and the master ECU 100.

[1.7 Configuration of Master ECU (Update Management Device) 100]
FIG. 7 is a configuration diagram of the master ECU 100. Master ECU 100 includes transmitting / receiving section 101, key holding section 102, determining section 103, level information holding section 104, frame transmitting / receiving section 160, frame interpreting section 150, receiving ID determining section 130, and receiving ID list holding. The configuration includes a unit 140, a frame processing unit 110, and a frame generation unit 120. Each of these components is a functional component, and each function is realized by a communication circuit in master ECU 100, a processor that executes a control program stored in a memory, a digital circuit, or the like.

  The transmission / reception unit 101 transmits the public key certificate 40c of the master ECU 100 for authentication between the master ECU 100 and the external tool 30 (the external tools 30a and 30b) and the public key certificate (the public key certificate 40a) from the external tool 30. Alternatively, the public key certificate 40b) is received. The transmission / reception unit 101 also receives an update message according to the CAN protocol transmitted from the external tool 30 to the bus 500d via the diagnostic port 600, and transmits an update result using the update message.

  The key holding unit 102 holds the public key certificate 40c, the secret key 50c, and the shared keys 60a to 60e of the master ECU 100. Note that a MAC key used when MAC is added as encryption processing to data in a data frame according to the CAN protocol may be held in the key holding unit 102. Further, a session key used for encryption processing related to communication with the external tool 30 or the like may be held in the key holding unit 102. The session key can also be used to generate a MAC.

  The frame transmitting / receiving unit 160 transmits / receives a frame to / from the bus 500b according to the CAN protocol. That is, frames from the ECUs 400a to 400f are received and transmitted to the ECUs 400a to 400f. The frame is received one bit at a time from the bus 500b and transmitted to the frame interpreter 150. Also, the contents of the frame notified from the frame generation unit 120 are transmitted to the bus 500b bit by bit.

  The frame interpreting unit 150 receives the value of the frame from the frame transmitting / receiving unit 160, and interprets it so as to map it to each field in the frame format specified by the CAN protocol. The frame interpretation unit 150 transfers the value (message ID) determined as the ID field to the reception ID determination unit 130. According to the determination result notified from the reception ID determination unit 130, the value of the ID field and the data field appearing after the ID field are transferred to the frame processing unit 110 or the reception of the frame is stopped (that is, the frame is stopped). To stop the interpretation). If the frame is determined not to conform to the CAN protocol, the frame generation unit 120 is notified to transmit an error frame. When the frame interpreting unit 150 receives an error frame, that is, when it interprets that the frame is an error frame based on the value in the received frame, it discards the frame thereafter, that is, stops interpreting the frame. I do.

  The reception ID determination unit 130 receives the value of the ID field notified from the frame interpretation unit 150, and receives each field of the frame after the ID field according to the message ID list held by the reception ID list holding unit 140. It is determined whether or not to do. The reception ID determination unit 130 notifies the frame interpretation unit 150 of this determination result. Further, similarly to the frame interpretation unit 150, the reception ID determination unit 130 determines whether the message ID is for a frame to be received, and notifies the determination unit 103 of the determination result.

  The reception ID list holding unit 140 holds a reception ID list, which is a list of message IDs received by the master ECU 100.

  The frame generation unit 120 composes an error frame in accordance with the error frame transmission request notified from the frame interpretation unit 150, and notifies the frame transmission / reception unit 160 of the error frame to transmit. Also, when receiving a frame generation instruction from the determination unit 103, the frame is configured by performing encryption processing on the data (for example, adding a MAC corresponding to a session key or the like) and notifying the frame transmission / reception unit 160 for transmission. Let it.

  The determining unit 103 authenticates the external tool 30 by verifying the public key certificate including the update authority information received from the external tool 30. If the determination unit 103 successfully verifies the public key certificate received from the external tool 30, it means that the external tool 30 has been successfully authenticated. Note that the success of the verification of the public key certificate by the determination unit 103 also means the success of the verification of the update authority information. When the transmission / reception unit 101 receives the update message, the determination unit 103 determines that the update authority information has been successfully verified and that the transmission of the update message is within the authority range of the external tool 30. By determining whether or not the information indicates, it is determined whether or not to permit the update corresponding to the update message. In this determination, the message ID of the received update message and the level indicated by the update authority information described in the received public key certificate are compared with the level information 1040 (described later) held by the level information holding unit 104. This is performed by determining whether or not the response is appropriate. The determination unit 103 determines that the update authority information indicates that the transmission of the update message made by the external tool 30 is within the authority range of the external tool 30 (that is, determines that the update message is a permitted update message). Instructs the frame generation unit 120 to generate a new update message that is a frame corresponding to the (original) update message for transfer to another ECU (that is, for transmission to the bus 500b). Note that the new update message generated for transfer by the frame generation unit 120 has the same message ID as the original update message and the data in the data field of the update message is substantially the same. When the data is applied, the encryption processing (for example, the MAC added to the data) applied to the data is different. The update message generated by the frame generation unit 120 is transmitted to the bus 500b by the frame transmission / reception unit 160. As a result, when the verification of the update authority information from the external tool 30 is successful and the update message from the external tool 30 is determined to be an allowed update message, the (Ie, to the bus 500b). When determining that the update message for updating the shared key from the external tool 30 is a permitted update message, the determination unit 103 updates the shared key held in the key holding unit 102.

  The frame processing unit 110 performs a predetermined process according to the data of the frame received from the bus 500b. When, for example, receiving a frame indicating the result of the update in each ECU by the update message from the bus 500b, the frame processing unit 110 generates a message (frame) containing the result of the update and transmits and receives the message (frame). To the bus 500d connected to the diagnostic port 600.

  The level information holding unit 104 holds the level information 1040.

[1.8 Level information]
FIG. 8 is a diagram illustrating an example of the level information 1040 held by the level information holding unit 104.

  The level information 1040 is information that associates the message ID 1041 with the level 1042, and is used by the determination unit 103 to determine whether to allow an update message from the external tool 30.

  The message ID 1041 indicates a message ID of an update message that can be transmitted from the external tool 30. Here, “0x100” to “0x104” are defined as the message IDs for the update message for updating the shared key held by the ECU, and “0x100” to “0x104” are set as the message IDs for the update message for updating the firmware of the ECU. Description will be made assuming that “0x200” to “0x206” are determined.

  Level 1042 indicates the level of authority required to transmit the update message of the corresponding message ID. This level corresponds to the level as the content of the update authority information. For example, if the value of the level indicated by the update authority information described in the public key certificate of the external tool 30 indicates a value indicating an authority equal to or higher than the value of the level 1042, the value is associated with the value of the level 1042. The external tool 30 has authority to transmit the update message of the received message ID 1041. Conversely, if the value of the level indicated by the update authority information described in the public key certificate of the external tool 30 is a value indicating authority lower than the value of the level 1042, the message ID 1041 associated with the level 1042 The external tool 30 does not have the authority to transmit the update message.

  The message ID “0x100” illustrated in FIG. 8 is a message ID for an update message for updating the shared key 60a held by the master ECU 100 and the ECUs 400a to 400f. In the level information 1040, the value of the level 1042 corresponding to the message ID “0x100” is set to 4, which is the highest. This value 4 is the highest level (specifically, the level corresponding to the safety and comfort function that is the function type of the ECU 400e) among the levels corresponding to the function types of the ECUs for which the shared key 60a is to be updated. (See FIG. 5).

  The message ID “0x101” is a message ID for an update message for updating the shared key 60e held by the master ECU 100 and the ECU 400e. The value of the level 1042 is set to 4 corresponding to the ECU 400e having the safety and comfort function.

  The message ID “0x102” is a message ID for an update message for updating the shared key 60d held by the master ECU 100 and the ECUs 400a and 400b. The value of the level 1042 is set to 3 corresponding to the ECU 400a having the drive system function and the ECU 400b having the chassis system function.

  The message ID “0x103” is a message ID for an update message for updating the shared key 60c held by the master ECU 100 and the ECUs 400c and 400d. The value of the level 1042 is set to 2 corresponding to the ECUs 400c and 400d having the body function.

  The message ID “0x104” is a message ID for an update message for updating the shared key 60b held by the master ECU 100 and the ECU 400f. The value of the level 1042 is set to 1 corresponding to the ECU 400f having the infotainment function.

  The message ID “0x200” is a message ID for an update message for updating the firmware of the master ECU 100. The value of the level 1042 corresponding to this message ID is set to the highest level of 4 by specially treating the master ECU 100.

  The message ID “0x201” is a message ID for an update message for updating the firmware of the ECU 400e. The value of the level 1042 corresponding to the message ID is set to 4 corresponding to the ECU 400e having the safety and comfort function.

  The message ID “0x202” is a message ID for an update message for updating the firmware of the ECU 400b. The value of the level 1042 corresponding to the message ID is set to 3 corresponding to the ECU 400b having the chassis function.

  The message ID “0x203” is a message ID for an update message for updating the firmware of the ECU 400a. The value of the level 1042 corresponding to the message ID is set to 3 corresponding to the ECU 400a having the drive system function.

  The message ID “0x204” is a message ID for an update message for updating the firmware of the ECU 400c. The value of the level 1042 corresponding to the message ID is set to 2 corresponding to the ECU 400c having the body function.

  The message ID “0x205” is a message ID for an update message for updating the firmware of the ECU 400d. The value of the level 1042 corresponding to the message ID is set to 2 corresponding to the ECU 400d having the body function.

  The message ID “0x206” is a message ID for an update message for updating the firmware of the ECU 400f. The value of the level 1042 corresponding to the message ID is set to 1 corresponding to the ECU 400f having the infotainment function.

[1.9 Configuration of ECU 400a]
FIG. 9 is a configuration diagram of the ECU 400a. The ECU 400a includes a key storage unit 402, a frame transmission / reception unit 460, a frame interpretation unit 450, a reception ID determination unit 430, a reception ID list storage unit 440, a frame processing unit 410, a frame generation unit 420, and a data acquisition unit. 470. Each of these components is a functional component, and each function is implemented by a communication circuit in the ECU 400a, a processor or a digital circuit that executes a control program stored in a memory, or the like. The ECUs 400b to 400f have basically the same configuration as the ECU 400a.

  The key holding unit 402 holds the shared key shown in FIG. That is, the key holding unit 402 of the ECU 400a holds the shared keys 60a and 60d. A MAC key used when MAC is added as encryption processing to data in a data frame according to the CAN protocol may be held in the key holding unit 402. Further, a session key used for encryption processing related to communication with another ECU or the like may be stored in the key storage unit 402. The session key can also be used to generate a MAC.

  The frame transmission / reception unit 460 transmits / receives a frame to / from the bus 500a according to the CAN protocol. The frame is received one bit at a time from the bus 500 a and transferred to the frame interpreter 450. Further, the contents of the frame notified from the frame generation unit 420 are transmitted to the bus 500a.

  The frame interpreting section 450 receives the value of the frame from the frame transmitting / receiving section 460 and interprets it so as to map it to each field in the CAN protocol. The value determined as the ID field is transferred to the reception ID determination unit 430. According to the determination result notified from the reception ID determination unit 430, the value of the ID field (message ID) and the data field appearing after the ID field are transferred to the frame processing unit 410 or the determination result is received. Thereafter, it is determined whether the reception of the frame is stopped (that is, the interpretation as the frame is stopped). If the frame is determined not to conform to the CAN protocol, the frame generation unit 420 is notified to transmit an error frame. When an error frame is received, that is, when the frame interpreting unit 450 interprets that the value is an error frame based on the value in the received frame, the frame interpreting unit 450 discards the frame thereafter, that is, stops interpreting the frame. I do.

  The reception ID determination unit 430 receives the value of the ID field notified from the frame interpretation unit 450, and receives each field of the frame after the ID field according to the message ID list held by the reception ID list holding unit 440. It is determined whether or not to do. The reception ID determination unit 430 notifies the frame interpretation unit 450 of this determination result.

  The reception ID list holding unit 440 holds a reception ID list (see FIG. 10), which is a list of message IDs received by the ECU 400a.

  The frame processing unit 410 performs a process related to a different function for each ECU according to the received frame data. For example, ECU 400a connected to engine 310 may perform predetermined control in accordance with the relationship between the rotational speed of engine 310 and the state of a part of the vehicle indicated by frame data received from another ECU.

  The data acquisition unit 470 acquires data indicating the state of the devices and sensors connected to the ECU, and notifies the frame generation unit 420 of the data.

  The frame generation unit 420 composes an error frame in accordance with the error frame transmission request notified from the frame interpretation unit 450, and notifies the frame transmission / reception unit 460 of the error frame to transmit. Further, the frame generation unit 420 configures a data frame by adding a predetermined message ID to the value of the data field determined based on the data notified from the data acquisition unit 470, and notifies the frame transmission / reception unit 460 of the data frame. To send. Note that the frame generation unit 420 can add the MAC generated using the MAC key or the session key to the value of the data field.

[1.10 Receive ID list]
FIG. 10 shows an example of the reception ID list 900 held by the reception ID list holding section 440 of the ECU 400a.

  The example of FIG. 10 shows that the ECU 400a receives an update message for updating the shared key with the message ID “0x102”, an update message for updating the firmware with the message ID “0x203”, and the like. ing. The message ID of the message (frame) received by the ECU 400a is not limited to “0x102” and “0x203”, but in the example of FIG. 10, the message ID of the update message is particularly noted.

  Note that, similarly to the reception ID list 900, the reception ID list held by the reception ID list holding unit 140 of the master ECU 100 has a configuration in which message IDs of messages that can be received by the master ECU 100 are listed.

[1.11 Shared key update sequence]
Hereinafter, as an example of the update management method, an operation (shared key update sequence) when the external tool 30a is connected to the diagnostic port 600 and the external tool 30a updates the shared key held by the ECU in the vehicle-mounted network system 10 will be described. This will be described with reference to FIGS.

  11 and 12 are diagrams illustrating an example of a shared key update sequence performed between the external tool 30a, the master ECU 100, and the ECU 400a. Here, for convenience, the description will focus on the external tool 30a as one of the external tools 30 and the ECU 400a which is one of the ECUs 400a to 400f. Further, the description will be made on the assumption that the external tool 30a is used to update the shared key held by each ECU having the drive system function and the chassis system function. Specifically, an update message to which a message ID “0x102” for updating the shared key 60d held by each of the ECU 400a having the drive system function and the ECU 400b having the chassis system function is transmitted from the external tool 30a to the in-vehicle network system. 10 will be sent. The operation of the ECU 400b is the same as the operation of the ECU 400a, and the description is omitted here.

  First, in a state where the external tool 30a is physically connected to the diagnostic port 600 connected to the master ECU 100 via the bus 500d, the external tool 30a transmits the certificate (that is, the public key certificate 40a held by the external tool 30a) to the bus. By transmitting the authentication request to the ECU 500, an authentication request is transmitted to the ECU 100 for communication connection (step S1001). The external tool 30a can transmit an update message for updating data (shared key, firmware) in the ECU of the in-vehicle network system 10 according to, for example, a user operation. However, in order for the update to be realized by the update message, it is necessary to transmit an authentication request (certificate) prior to the transmission of the update message, for example, in response to a user operation or the like.

  The transmitting / receiving unit 101 of the master ECU 100 receives the public key certificate 40a, and the determining unit 103 verifies the public key certificate 40a (step S1002). For verification of the public key certificate 40a, for example, a signature by a certificate authority is verified, and a private key corresponding to the public key described in the public key certificate 40a is challenged by a challenge response (CR) authentication method. Check if is retained. In the CR authentication method, for example, when the master ECU 100 transmits a random number to the external tool 30a and returns the encrypted random number, which is a result of encrypting the random number with the secret key, to the master ECU 100, the master ECU releases The encrypted random number is decrypted with the public key in the key certificate 40a, and it is confirmed whether the decrypted random number is equal to the first transmitted random number. If the verification in step S1002 fails, master ECU 100 performs error processing (step S1003). Due to the error processing in step S1003, communication connection from the external tool 30a is not recognized, and the external tool 30a cannot update the ECU data by transmitting, for example, an update message. The master ECU 100 may or may not return a response to the external tool 30a indicating an error as an error process.

  If the verification in step S1002 succeeds, master ECU 100 generates a session key used for performing encryption processing in communication with external tool 30a using a random number (step S1004). For example, when encrypting data in an update message, the session key is used as a key for encryption, and when adding a MAC to the data in the update message, the session key generates a MAC. Used as a key to

  Subsequent to step S1004, the transmission / reception unit 101 of the master ECU 100 encrypts the session key with the public key of the external tool 30a, and transmits the encrypted session key that is the result of the encryption and the public key certificate 40c of the master ECU 100. The data is transmitted to the external tool 30a (step S1005).

  The external tool 30a verifies the public key certificate 40c of the master ECU 100 (step S1006). If the verification fails, error processing is performed (step S1007). If the verification is successful, the external tool 30a obtains the session key by decrypting the encrypted session key transmitted and received from the master ECU 100 in step S1004 with the secret key held by the external tool 30a (step S1004). S1008).

  After step S1008, the external tool 30a generates an update message for updating the shared key 60d to which the message ID “0x102” is attached, and performs an encryption process on the update message using the session key (step S1009) ). As an example of the encryption processing on the update message, data required for updating the shared key 60d, for example, data necessary for updating the shared key 60d (for example, data to be used as the key when the ECU 400a performs updating using a keyed hash function or the like) And encrypting the data or adding a MAC to the data. Further, even when data is not required for updating the shared key 60d, for example, the MAC corresponding to the whole or a part of the update message can be stored in the data field. For example, in the in-vehicle network system 10, a predetermined encryption process (that is, a predetermined encryption process using a session key) to be performed is defined in advance as to what process is to be performed as the encryption process corresponding to the update message. Then, each ECU performs an update corresponding to the update message in which the predetermined encryption processing (for example, the addition of the MAC) is appropriately performed (that is, the verification using the session key is successful) in accordance with the regulation, and the predetermined encryption processing is performed. If the processing has not been properly performed, the update of the update message is suppressed.

  External tool 30a transmits the update message generated in step S1009 to master ECU 100 (step S1010).

  The determination unit 103 determines whether the message ID of the message (frame) received by the transmission / reception unit 101 of the master ECU 100 by the transmission by the external tool 30a in step S1010 is an ID to be received by the reception ID determination unit 130. (Step S1011). The message IDs “0x100” to “0x104” for updating the shared key and the message IDs “0x200” to “0x206” for updating the firmware are determined to be IDs to be received. Here, since the description is made assuming that the external tool 30a transmits an update message, a message (frame) from the external tool 30a is referred to as an update message. Therefore, a determination is made in step S1011. That is, if the message (frame) transmitted from the external tool 30a is actually an update message, it is determined that it should be received. Here, for convenience of explanation, the master ECU 100 does not treat a message ID of a message other than an update message from the external tool 30 (for example, the external tool 30a) connected to the diagnostic port 600 as an ID to be received. .

  In step S1011, if the message ID of the message received by the transmitting / receiving unit 101 is determined not to be an ID to be received, the determining unit 103 of the master ECU 100 stops the process related to the message of the message ID, and In 101, the process ends without receiving the contents (data field and the like) after the ID field (step S1012).

  In step S1011, if the message ID of the message received by the transmitting / receiving unit 101 is determined to be an ID to be received, the determination unit 103 of the master ECU 100 determines the message ID “0x102” of the received message and the external tool 30a. Depends on whether or not the level of the update authority information described in the public key certificate 40a matches the correspondence between the message ID 1041 and the level 1042 in the level information 1040 held in the level information holding unit 104. It is determined whether the received message is an allowed update message (step S1013). That is, the determination unit 103 determines, based on the level information 1040, whether or not the update authority information indicates that the transmission of the update message by the external tool 30a is within the authority range of the external tool 30a. If the received message is not a permitted update message, error processing is performed (step S1014). By the error processing in step S1014, the update corresponding to the update message is suppressed. Here, assuming that the level of the update authority information of the public key certificate 40a is 3 (see FIG. 3), the correspondence with the update message of the message ID “0x102” is the correspondence indicated by the level information 1040 (FIG. 8). Therefore, the determination unit 103 determines that the update message received from the external tool 30a is a permitted update message.

  If it is determined in step S1013 that the transmission of the received message is within the authority range of the external tool 30a (that is, if it is determined that the received message is an allowed update message), the determination unit 103 sets the frame It instructs the generation unit 120 to generate an update message for transfer (step S1015). Thereby, in frame generating section 120, based on the original update message received by master ECU 100 from external tool 30a, a new update message (frame) for transfer to bus 500b (that is, for transfer to another ECU) is provided. Generate For example, when the session key used for communication with the external tool 30a by the master ECU 100 is different from the session key used for communication with another ECU (at least each ECU connected to the bus 500b), frame generation is performed. The unit 120 performs decryption using a session key for communication with the external tool 30a if the encryption processing performed on the original update message is encryption, and uses the result of the processing for communication with another ECU. A new update message is generated by performing encryption using the session key. If the encryption processing performed on the original update message is addition of a MAC, the frame generation unit 120 generates a MAC using a session key used for communication with another ECU, and generates the MAC of the original update message. Is replaced with the generated MAC to generate a new update message. In this case, the MAC of the original update message may be verified, and if the verification fails, error processing may be performed. Also, for example, when the master ECU 100 uses the same session key used for communication with the external tool 30a and the session key used for communication with another ECU, the frame generation unit 120 determines whether the original update message Generate the same new update message.

  Subsequent to step S1015, the frame transmission / reception unit 160 sends the update message generated by the frame generation unit 120 of the master ECU 100 to the bus 500b (step S1016). That is, when the update message is transmitted from external tool 30a, master ECU 100 determines that the update authority information has been successfully verified (that is, the public key certificate has been verified), and that the transmission of the update message has been performed by external tool 30a. When the update authority information indicates that the information is within the authority range, the update message is transferred to the bus 500b. When the verification of the update authority information has failed, or when the update authority information does not indicate that the transmission of the update message is within the authority range of the external tool 30a, the transfer of the update message to the bus 500b is performed. I can't.

  The update message sent to bus 500b by master ECU 100 is transferred by gateway 300 to buses 500a and 500c. Thus, the ECUs 400a to 400f can receive the update message. Therefore, when the master ECU 100 determines that the update authority information indicates that the transmission of the update message of a certain message ID is within the authority range of the external tool 30a, it is predetermined to receive the update message of the message ID. The update corresponding to the update message can be executed by the ECU.

  In the ECU 400a (see FIG. 9), the update message is received by the frame transmission / reception unit 460, the content of the message is interpreted by the frame interpretation unit 450, and an inquiry is made to the reception ID determination unit 430 as to whether there is an ID to be received. The reception ID determining unit 430 refers to the reception ID list stored in the reception ID list storage unit 440, and determines whether the value of the ID field of the received message is an ID to be received (step S1017). If the reception ID determination unit 430 determines in step S1017 that the message ID of the message received by the frame transmission / reception unit 460 is not an ID to be received, the frame interpretation unit 450 determines whether the received message is The processing is stopped, and the frame transmission / reception section 460 ends the processing without receiving the contents after the ID field (step S1018).

  If the reception ID determination unit 430 determines in step S1017 that the value of the ID field of the message received by the frame transmission / reception unit 460 is the ID to be received, the ECU 400a sends the message to the frame processing unit 410. The process corresponding to the update message (that is, the update of the shared key 60d) is performed (step S1019). The frame processing unit 410 uses the keyed data in the data field of the update message to generate a new shared key 60d to be updated from the shared key 60d currently held by the key holding unit 402 by using a keyed hash function. Generate. It is not always necessary to use a hash function with a key for updating, and another example is to update an original shared key to a new shared key using a hash function without keys (one-way function). Can be In the ECU 400a, a process (decryption or MAC verification) corresponding to the encryption process (encryption or MAC addition) performed on the update message is performed using the session key to obtain key data of the update message.

  After updating shared key 60d, ECU 400a sends a message indicating the result of the update (referred to as an update result message) to bus 500a so as to be transmitted to master ECU 100 (S1020). Note that the message ID of the update result message is predetermined, and the master ECU 100 holds the message ID of the update result message in a list of the reception ID list holding unit 140. The update result message indicates, for example, that the update has been completed (that is, the update has been successful). When an error occurs during the update (for example, when the MAC verification of the key data fails), the update result message may indicate that the update has failed. The update result message is transferred from the bus 500a to the bus 500b by the gateway 300.

  Upon receiving the update result message, master ECU 100 updates shared key 60d (see FIG. 6) held by key holding unit 102 in the same manner as ECU 400a (step S1021). The master ECU 100 holds the key holding unit 102 only when receiving both the update result message indicating the update success from the ECU 400a and the update result message indicating the update success from the ECU 400b. The shared key 60d may be updated.

  Master ECU 100 transmits the update result message received in step S1020 to external tool 30a via diagnostic port 600 by transmitting the update result message to bus 500d (step S1022). As a result, the external tool 30a receives the update result message and knows that the target update has been completed in the in-vehicle network system 10, and notifies the user of the update completion (for example, the external tool 30a has a display device). Display, etc.).

  As described above, the example in which the external tool 30a transmits the update message for updating the shared key 60d held by each of the ECUs 400a and 400b and the master ECU 100 has been described. However, the update message for updating the shared key held by other ECUs is shown. Is transmitted, or when an update message for updating the firmware in the ECU is transmitted, each device performs the same operation. After transmitting the authentication request once, the external tool 30a may sequentially transmit each update message. In this case, after the processing from step S1001 to step S1008 is executed once, the processing after step S1009 is repeated each time the external tool 30a transmits each update message. Further, the update message for updating the firmware in the ECU includes, for example, information for specifying the content of the updated firmware, and the target ECU of the update message specifies the content of the updated firmware. Rewrite the firmware based on the information of The firmware includes, for example, software such as a program in the ECU, data used in the program, and may include, for example, microcode in a processor in the ECU. Further, the firmware may include data for circuit configuration, for example, when the ECU includes an FPGA (Field Programmable Gate Array) or the like. In this description, the shared key and the firmware are handled separately for the sake of convenience, but the firmware may be handled as including the shared key.

[1.12 Effects of First Embodiment]
In the in-vehicle network system 10 according to the first embodiment, whether the external tool 30 connected to the diagnostic port 600 has the authority to transmit an update message for updating data in a specific ECU, that is, whether the external tool 30 Whether or not the user has the authority to update the data in the ECU is determined based on the level defined in accordance with the function type of the ECU indicated by the update authority information indicating the authority authorized to the external tool 30. doing. This can prevent the update of the shared key or the firmware in the ECU by an unauthorized external tool. Also. For each external tool, for example, the level of the update authority information can be set (and certified) in accordance with the confidentiality and reliability of the external tool, the reliability of the business operator handling the external tool, and other various circumstances. It is also possible to distribute external tools of different levels to different maintenance companies and the like, and it is possible to flexibly restrict the updating authority according to various circumstances. For example, an external tool with sufficient security such as confidentiality and reliability can recognize a higher authority level. The ability to set the level of the update authority information for each external tool in this way is used to efficiently and flexibly design and manufacture the external tool according to the application, or to ensure the security of the operation of the external tool. It will be useful to perform it flexibly according to.

(Embodiment 2)
Hereinafter, an in-vehicle network system 10a obtained by partially modifying the in-vehicle network system 10 described in the first embodiment will be described.

  In the in-vehicle network system 10 according to the first embodiment, when the external tool 30 is connected to the diagnostic port 600, the master ECU 100 authenticates the external tool 30 and updates the update message from the external tool 30 with the update authority information. The external tool 30 is permitted to update the data in the ECU with the update message only when the authority (level) is within the range shown.

  In the in-vehicle network system 10a according to the present embodiment, in determining whether or not to allow the update message of the external tool 30, not only the level but also the state of the vehicle equipped with the in-vehicle network system 10a and the battery in the vehicle Refer to the remaining battery status. The configuration of the in-vehicle network system 10a according to the present embodiment is substantially the same as that of the in-vehicle network system 10 (see FIG. 1) shown in the first embodiment, and the same reference numerals are used for the same components as those in the first embodiment. .

[2.1 Overall Configuration of In-Vehicle Network System 10a]
FIG. 13 is a diagram illustrating an overall configuration of the vehicle-mounted network system 10a according to the second embodiment. FIG. 2 shows an external tool 30 in addition to the vehicle-mounted network system 10a.

  In the vehicle-mounted network system 10a, a storage battery 800 and an ECU 400g are added to the vehicle-mounted network system 10 (FIG. 1). Here, the description of the same components as those in the first embodiment will be omitted.

  The ECU 400g is connected to the bus 500b, controls charging / discharging of the battery (storage battery) 800, acquires and manages the remaining amount of the storage battery 800, and periodically transmits a frame representing the state of the remaining battery to a network (that is, a network). To the bus 500b).

  The storage battery 800 supplies electric power to each ECU in the in-vehicle network system 10.

[2.2 Level information]
FIG. 14 is a diagram illustrating an example of the level information 2040 held by the level information holding unit 104 of the master ECU 100 according to the second embodiment.

  The level information 2040 is information in which the message ID 2014, the level 2042, the battery remaining amount condition 2043, and the vehicle state condition 2044 are associated, and the determination unit 103 determines whether to permit an update message from the external tool 30. Used. The message ID 2041 and the level 2042 are the same as the message ID 1041 and the level 1042 shown in the first embodiment. The battery remaining amount condition 2043 indicates a condition of the remaining amount of the battery required to permit the update message. For example, the remaining amount of the battery is set to a sufficient amount so that the remaining amount of the battery is sufficient for updating. One of a remaining amount of 50% or more of charging and a remaining amount of 80% or more of charging is set assuming that the full charge amount is 100%. The vehicle state condition 2044 indicates a vehicle state condition required for permitting the update message, and includes, for example, a stopped state (a state where the vehicle speed is zero) and an engine OFF state (the engine 310 is stopped). Is set.

  For example, the update message for updating the shared key with the message ID “0x104” has an update authority information level of 1 or more, the remaining battery capacity of the storage battery 800 is 50% or more, and the vehicle state is the stopped state. Indicates that it is permitted. The update message for updating the firmware with the message ID “0x201” is when the level of the update authority information is 4, the battery level of the storage battery 800 is 80% or more, and the vehicle state is the engine OFF state. Is allowed.

[2.3 Shared key update sequence]
Hereinafter, as an example of the update management method, an operation (shared key update sequence) when the external tool 30a is connected to the diagnostic port 600 and the external tool 30a updates the shared key held by the ECU in the in-vehicle network system 10a will be described. This will be described with reference to FIGS.

  FIGS. 15 and 16 are diagrams illustrating an example of a shared key update sequence performed between the external tool 30a, the master ECU 100, and the ECU 400a. Here, for convenience, the description will focus on the external tool 30a as one of the external tools 30, and the ECU 400a which is one of the ECUs 400a to 400g. Further, the description will be made on the assumption that the external tool 30a is used to update the shared key held by each ECU having the drive system function and the chassis system function. Specifically, an update message to which a message ID “0x102” for updating the shared key 60d held by each of the ECU 400a having the drive system function and the ECU 400b having the chassis system function is transmitted from the external tool 30a to the in-vehicle network system. 10 will be sent. The operation of the ECU 400b is the same as the operation of the ECU 400a, and the description is omitted here. Also, the processing from step S2001 to step S2012 and step S2014 to step S2022 is equivalent to the processing from step S1001 to step S1012 and step S1014 to step S1022 shown in Embodiment 1 (see FIGS. 11 and 12). The description is omitted, and here, only steps S2013a to S2013c different from the first embodiment will be described.

  In step S2013a, the determination unit 103 of the master ECU 100 stores the message ID “0x102” of the received message and the level of the update authority information described in the public key certificate 40a of the external tool 30a in the level information storage unit 104. It is determined whether or not the received message satisfies the condition of the authority level as an appropriate update message based on whether or not the correspondence between the message ID 2041 and the level 2042 in the level information 2040 described above matches. That is, the determination unit 103 determines whether the update authority information indicates that the transmission of the update message by the external tool 30a is within the authority range of the external tool 30a, based on the level information 2040. If the received message does not satisfy the condition of the authority level, error processing is performed (step S2014). Here, assuming that the level of the update authority information of the public key certificate 40a is 3 (see FIG. 3), the correspondence with the update message of the message ID “0x102” is the correspondence indicated by the level information 2040 (FIG. 14). Therefore, the determination unit 103 determines that the update message received from the external tool 30a is an appropriate update message in terms of level, and shifts the processing to the next step S2013b.

  In step S2013b, the determination unit 103 checks whether the remaining battery capacity of the storage battery 800 satisfies the condition. When ECU 400g that manages the remaining battery level of storage battery 800 periodically transmits a message indicating the state of the remaining battery level (referred to as a remaining battery level frame), master ECU 100 transmits the remaining battery level frame from ECU 400g. The data is received by the frame transmitting / receiving unit 160. It is assumed that the reception ID list held by reception ID list holding section 140 of master ECU 100 includes the message ID of the battery remaining amount frame from ECU 400g. The determination unit 103 checks whether the remaining battery level indicated by the remaining battery level frame received from the ECU 400g satisfies the remaining battery level condition 2043 corresponding to the message ID 2041 held in the level information holding unit 104. If the condition of the remaining battery level is satisfied, the process moves to the next step S2013c. If the condition of the remaining battery level is not satisfied (that is, if the check result is NG), error processing is performed (step S2014). Note that the ECU 400g may not periodically transmit the battery remaining amount frame indicating the state of the battery remaining amount. In this case, in step S2013b, the master ECU 100 requests the ECU 400g to transmit the battery remaining amount frame, for example. By transmitting the frame, the battery remaining amount frame may be received from the ECU 400g, and the state of the battery remaining amount at the time when the update message is received (that is, at the present time) may be acquired.

  In step S2013c, the determination unit 103 checks whether the vehicle state satisfies the condition. When ECU 400a related to engine 310 periodically transmits a message (referred to as a vehicle state frame) indicating vehicle state information such as an engine state and a vehicle speed, master ECU 100 transmits a vehicle state frame from ECU 400a to a frame transmission / reception unit. Receive at 160. It is assumed that the reception ID list held by reception ID list holding section 140 of master ECU 100 includes the message ID of the vehicle state frame from ECU 400a. The determination unit 103 checks whether the vehicle state such as the engine state and the vehicle speed indicated by the vehicle state frame received from the ECU 400a satisfies the vehicle state condition 2044 corresponding to the message ID 2041 held in the level information holding unit 104. I do. If the condition of the vehicle state is satisfied, the determination unit 103 determines that the update message received from the external tool 30a is permitted, and shifts the processing to step S2015. If the condition of the vehicle state is not satisfied (that is, if the result of the check is NG), error processing is performed (step S2014). The ECU 400a may not periodically transmit the vehicle state frame. In this case, in step S2013c, the master ECU 100 transmits a frame requesting the transmission of the vehicle state frame to the ECU 400a. The vehicle state frame at the time when the update message is received (that is, at the present time) may be obtained by receiving the vehicle state frame.

[2.4 Effects of Second Embodiment]
In the in-vehicle network system 10a according to the second embodiment, as to whether or not to permit the processing (update) related to the update message from the external tool 30, depending on not only the authority level but also the state of the remaining battery level and the vehicle state. In such a case, the determination is made according to whether the update message has been transmitted. Therefore, in addition to the effects of the in-vehicle network system 10 according to the first embodiment, the following effects are provided. That is, by confirming the remaining battery level, the update process of the data (shared key or firmware) in the ECU can be surely completed without interruption. Also, by confirming the vehicle state, for example, when the load on the ECU is high and the bus traffic increases when the vehicle is running, for example, it is possible to avoid performing the update by transmitting the update message, thereby reducing the possibility of the update being successful. Enhanced.

(Embodiment 3)
In the present embodiment, an example will be described in which the master ECU 100 in the in-vehicle network system 10 according to the first embodiment is partially modified so as to be able to notify the expiration date of the shared key.

[3.1 Configuration of Master ECU (Update Management Device) 100a]
FIG. 17 is a configuration diagram of the master ECU 100a. Master ECU 100a has a configuration in which a time information acquisition unit 180 and a key update confirmation unit 190 are added to the components of master ECU 100 shown in the first embodiment to check the expiration date of the shared key. Each of these components is a functional component, and each function is realized by a communication circuit in master ECU 100a, a processor that executes a control program stored in a memory, a digital circuit, or the like. Here, the description of the components described in Embodiment 1 is omitted.

  The time information acquisition unit 180 is configured by a time measurement mechanism such as a real-time clock, acquires the current time (that is, the current date and time), and sequentially notifies the key update confirmation unit 190.

  The key update confirmation unit 190 confirms the current time notified from the time information acquisition unit 180 and the expiration date predetermined for the shared key held by the key holding unit 102, and is set in advance as an alert notification timing. At a point in time after the current time (that is, a certain period before the expiration date), the key update alert message is generated by the frame generation unit 120 and transmitted from the frame transmission / reception unit 160.

  FIG. 18 illustrates an example of information in which the shared key identification information 3310, the expiration date 3311, and the alert notification timing 3312 are associated with each other for the shared keys held by the key holding unit 102. The shared key identification information 3310 is information for distinguishing each shared key. The expiration date 3311 indicates a predetermined expiration date for ensuring security for the shared key indicated by the corresponding shared key identification information. The alert notification timing 3312 indicates a timing at which a key update should be prompted prior to the expiration date. The key update confirmation unit 190 refers to the information shown in FIG. For example, the shared key 60a transmits a key update alert message three months before the expiration date, and the shared key 60d transmits a key update alert message one month before the expiration date.

  The key update alert message is received by ECU 400f connected to head unit 200. Upon receiving the key update alert message, ECU 400f displays, on the display device of head unit 200, warning information (screen) for urging the update of the shared key, indicating that the expiration date of the shared key is approaching.

[3.2 Key update alert message]
FIG. 19 is a diagram illustrating an example of a screen displayed on the display device of the head unit 200 when the expiration date of the shared key is approaching.

  In the example of FIG. 19, the screen 3320 includes the current date and time and the expiration date of the shared key of the ECU, and further, the contact information of the maintenance company (dealer in this example) for updating the shared key, and the website of the website. It includes a URL (Uniform Resource Locator). The screen 3320 includes a GUI (Graphical User Interface) button 3321 for transitioning to a screen for setting the destination to the address of the dealer by the navigation system. The information of the dealer may be registered in advance in the master ECU 100a at the time of sale, for example, or may be acquired via an ECU having a telematics function.

  For example, if the driver who looks at the screen 3320 illustrated in FIG. 19 drives the vehicle and goes to a maintenance company such as a dealer, the dealer or the like can use the external tool 30 as described in the first and second embodiments. Can be used to update the shared key held by the ECU in the in-vehicle network system.

[3.3 Effects of Third Embodiment]
In the in-vehicle network system according to the third embodiment, the expiration date of the shared key is managed, and when the expiration date is approaching, warning information (screen) prompting the driver of the vehicle to update the key is displayed on the head unit. Display on the display device. Thus, an alert for ensuring security related to the shared key, such as a warning that maintenance should be received at a dealer or the like, is realized.

(Embodiment 4)
In the present embodiment, the master ECU 100 in the in-vehicle network system 10 according to the first embodiment is modified so that the update result message is attached to the vehicle identification information and transmitted to the external tool 30, and the external tool 30 An example in which communication is performed will be described.

[4.1 Server]
The server 35 that communicates with the external tool 30 is a computer located outside the vehicle on which the vehicle-mounted network system 10 is mounted. Assuming that the in-vehicle network system 10 is installed in each of the plurality of vehicles, the server 35 determines which update (data in the ECU is to be performed) for which vehicle (that is, the in-vehicle network system). Update).

[4.2 Shared key update sequence]
Hereinafter, as an example of the update management method in the present embodiment, an external tool 30a that communicates with the server 35 is connected to the diagnostic port 600 in the vehicle-mounted network system 10 of a certain vehicle, and the external tool 30a is connected to the vehicle-mounted network system 10 by the external tool 30a. The operation of updating the shared key held by the ECU (shared key update sequence) will be described with reference to FIGS.

  20 and 21 are diagrams illustrating an example of a shared key update sequence performed between the external tool 30a communicating with the server 35, the master ECU 100, and the ECU 400a. The processing from step S3001 to step S3021 is the same as the processing from step S1001 to step S1021 shown in the first embodiment (see FIGS. 11 and 12), and thus the description is omitted, and here, the processing is different from the first embodiment. Only steps S3000a, S3000b, S3022, S3023 and S3024 will be described.

  In step S3000a, the external tool 30a issues a connection request to the server 35. That is, the external tool 30a transmits a login request using, for example, an ID (for example, a tool ID) and a password registered in advance to the server 35.

  In step S3000b, the server 35 receives the connection request from the external tool 30a, and if the ID and the password match the information registered in advance, performs a login process and returns a normal response.

  After step S3000b, the external tool 30a, the master ECU 100, and the ECU 400a perform the process related to the update of the shared key as described in the first embodiment. Thus, in step S3020, master ECU 100 has received an update result message indicating the update result from ECU 400a.

  In step S3022, master ECU 100 transmits, to bus 500d, an update result message with vehicle identification information, which is a message including vehicle identification information, in addition to the update result from ECU 400a, to external tool 30a via diagnostic port 600. Send to As a result, the external tool 30a receives the update result message with the vehicle identification information. The vehicle identification information only needs to be information that identifies the in-vehicle network system to which the external tool 30a is connected among a plurality of in-vehicle network systems. For example, the public key certificate 40c of the master ECU 100 (see FIG. 3) or the like is sufficient. is there.

  In step S3023, the external tool 30a transmits to the server 35 the vehicle identification information and the update result indicated by the received update result message with the vehicle identification information.

  In step S3024, the server 35 stores the received vehicle identification information and update result, the current date and time, and the log information 4000 in association with the ID received at the time of login.

[4.3 Diagnostic log information]
FIG. 22 is a diagram illustrating an example of the log information 4000 stored by the server 35. The log information 4000 includes vehicle identification information 4001, an external tool ID 4002, a message ID 4003 of an update message, a date and time 4004, and an update result 4005.

[4.4 Effect of Fourth Embodiment]
In the present embodiment, the server 35 stores the log information 4000 and information such as which vehicle has been updated by which external tool remains, so that the maintenance status can be grasped. Further, when an unauthorized external tool is found, the log information 4000 can be used for specifying the range of influence by the external tool.

(Other embodiments)
As described above, the first to fourth embodiments have been described as examples of the technology according to the present invention. However, the technology according to the present invention is not limited to this, and can be applied to embodiments in which changes, replacements, additions, omissions, and the like are made as appropriate. For example, the following modifications are also included in an embodiment of the present invention.

  (1) The shared key described in the above embodiment is an example in which the shared range is distinguished by the function type for classifying the function. However, the present invention is not limited to this. The unit with which the ECU has a shared key can be arbitrarily determined in the vehicle-mounted network system. For example, the in-vehicle network may be divided into a plurality of domains and a shared key may be set for each domain. In this case, the level information may be set to distinguish the domain as the level of authority required for updating. Further, in the above-described embodiment, an example is described in which the external tool 30 has the public key certificate including the update authority information in which the authority level is set based on the function type. May have a public key certificate including update authority information in which the authority is set.

  (2) In the above embodiment, the shared key is updated by generating a new shared key from the shared key currently held by each ECU by using a hash function with a key. The tool 30 may transmit the new shared key itself in the update message. In this case, if the value of the shared key does not fit in one frame of CAN, the value may be divided into a plurality of frames and transmitted.

  (3) In the above-described embodiment, an example has been described in which an update message for updating data (shared key, firmware, and the like) in the ECU is transmitted from the external tool 30. In addition, a message for failure diagnosis and the like is transmitted. Can send. For a message other than the update message, the in-vehicle network system (for example, the master ECU) may perform a process corresponding to the message without performing the authority determination based on the level information. Further, for any message including a message for failure diagnosis or the like, authority information indicating the level of authority indicating whether transmission of the message is within the authority range authorized by the external tool 30 in the vehicle-mounted network system (for example, the master ECU). May be determined based on

  (4) In the above embodiment, the authority level is set from 1 to 4, but the level does not have to be four, and may be higher or lower.

  (5) The method of classifying the function types described in the above-described embodiment is merely an example, and may be, for example, more detailed. The function type may be categorized most finely, and for example, the level of authority for updating data in the ECU may be set for each ECU.

  (6) In the second embodiment, an example is described in which the remaining battery condition 2043 is distinguished by the percentage (percentage) of the storage battery 800 with respect to full charge, but may be distinguished by the voltage of the storage battery 800 or the like. Further, a condition for distinguishing whether or not the storage battery 800 is being charged from an external power supply located outside the vehicle may be set. As a result, for example, it is possible to permit updating of a certain shared key and firmware only during charging.

  (7) In the third embodiment, an example is shown in which, when the expiration date of the shared key is approaching, information (screen) indicating that the expiration date of the key update is approaching is displayed based on the key update alert message. However, the information may be displayed repeatedly or continuously, or a warning (e.g., display) may be issued when the expiration date has expired.

  (8) In the third embodiment, an example has been described in which the time information acquisition unit 180 of the master ECU 100a acquires the current time by a timekeeping mechanism in order to check the expiration date of the shared key. The time information indicating the current time may be obtained from the telephone carrier network, or the time information may be obtained from a GPS (Global Positioning System) signal. Further, master ECU 100a may acquire time information from another ECU.

  (9) The external tool 30 described in the above embodiment may acquire the update message by receiving it from the server and transfer the acquired update message to the master ECU via the diagnostic port 600.

  (10) In the above embodiment, the authentication is performed between the external tool 30 and the master ECU. However, an electronic circuit (for example, a memory, a processor, etc.) responsible for the authentication is connected to the diagnostic port 600 which is a connector or the like compliant with the OBD2. ) May be added to authenticate the external tool 30 at the diagnostic port 600. In this case, if the authentication of the external tool 30 has been completed by the diagnostic port 600, the master ECU may omit the authentication of the external tool 30. Even if the authentication of the external tool 30 has been completed by the diagnostic port 600, the authentication may be performed between the external tool 30 and the master ECU as described in the above embodiment. The diagnostic port 600 may be realized by another connector instead of a connector or the like compliant with OBD2. Further, the diagnosis port 600 may be realized by including a wireless communication circuit so that the diagnosis port 600 can be connected to the external tool 30 by wireless communication.

  (11) In the second embodiment, the example in which master ECU 100 checks the state of the remaining battery and the state of the vehicle when receiving the update message has been described, but only one of the state of the battery and the state of the vehicle is checked. It is good. Further, the update authority information may indicate not only the authority level, but also the update authority conditions such as the remaining battery condition and the vehicle state condition described in the second embodiment. For example, the update authority information specifies, as the vehicle state condition, a stopped state, which is the state of the vehicle, or a state in which the engine has been stopped, and at least one state that the vehicle transmits an update message when the vehicle is in the specified state. One condition may be that the external tool has the authority to cause the ECU to update. Also, for example, the update authority information specifies the state of the remaining battery level for supplying power to the ECU as the remaining battery level condition, and sends an update message when the battery has the specified remaining battery level. The transmission may be represented as at least one condition indicating that the external tool has the authority to cause the ECU to perform the update. Then, for example, master ECU 100 performs a check (steps S2013b and S2013c) based on the remaining battery condition and the vehicle condition indicated by the update authority information instead of remaining battery condition 2043 and vehicle condition 2044 in level information 2040. It may be performed. As a result, the authority with a certain condition is recognized for the external tool according to the reliability of the external tool, etc., and the public key certificate that describes the updated authority information indicating the condition and the level of the authority is obtained. Operation such as issuing is possible.

  (12) In the above embodiment, the data frame in the CAN protocol is described in the standard ID format, but may be in the extended ID format. In the case of the extended ID format, the message ID is represented by 29 bits including the base ID of the ID position in the standard ID format and the extended ID.

  (13) In the above-described embodiment, an example has been described in which another ECU is not connected to the bus 500d that connects the diagnostic port 600 to which the external tool 30 is connected and the master ECU, but an ECU may be connected. . However, an ECU other than the master ECU and connected to the bus 500d transmits the data (shared key, firmware, etc.) by the external tool 30 (for example, the external tool 30 that has been successfully authenticated by the master ECU and obtained the session key). It can be updated by an update message. For this reason, for example, it is useful to connect to the bus 500d only for an ECU or the like having a function of a function type corresponding to the lowest level of update authority.

  (14) In the above embodiment, when the external tool 30 transmits an update message instructing the ECU to update beyond the level of the authorized authority, the master ECU determines that the update message is an allowed update message. Is determined (step S1013), and if the message is not an allowed update message, error processing is performed (step S1014), and the update corresponding to the update message is suppressed. However, an ECU other than the master ECU (for example, an ECU to be instructed to update by an update message) may switch whether to execute or inhibit the update based on the update authority information of the external tool 30. That is, in one of the ECUs of the in-vehicle network system, when the update message is transmitted from the external tool 30, the verification of the update authority information is successful, and the transmission of the update message is within the authority range of the external tool 30. When the update authority information indicates that, the update is executed by one or more ECUs in response to the update message, and when the verification fails, or the transmission of the update message is within the authority range of the external tool 30. When the update authority information does not indicate that, the update corresponding to the update message by one or a plurality of ECUs may be suppressed. It is to be noted that a method in which the master ECU switches whether or not to transfer update messages collectively as described in the embodiment is useful in terms of efficiency. The gateway 300 manages the function type of the ECU connected to the transfer destination bus or the message ID receivable by the ECU. When the gateway 300 receives the update message, the gateway 300 connects to the transfer destination bus. Unnecessary transfer of the update message may not be performed based on the function type of the ECU or the message ID that the ECU can receive.

  (15) The functional configuration of the master ECUs 100, 100a, the ECU 400a, and the like described in the above embodiment is merely an example, and a functional division different from the above-described functional configuration may be performed. For example, master ECUs 100 and 100a include a receiving unit corresponding to the receiving function of transmitting / receiving unit 101, a verifying unit responsible for verifying a public key certificate (a public key certificate including update authority information) in determining unit 103, and a determining unit 103. , A part of the frame generation unit 120, and a part of the frame transmission / reception unit 160, and may include a transfer unit that controls the transmission of the update message. In this case, for example, the receiving unit transmits update authority information indicating authority of the external tool 30 transmitted from the external tool 30 connected to the diagnostic port 600 via the diagnostic port 600, and one or more ECUs. Has a function of receiving an update message instructing the update of the data held by. Further, the verification unit has a function of verifying the update authority information received by the reception unit. In addition, when the update message is received by the receiving unit, when the verification by the verification unit succeeds and the update authority information indicates that the transmission of the update message is within the authority range of the external tool 30, the transfer unit transmits the update message. Function to transfer the update message to the bus 500b and, when the verification by the verification unit fails, or when the update authority information does not indicate that the transmission of the update message is within the authority range of the external tool 30, the transfer is inhibited. Carry. Further, the control program executed by the processors in master ECUs 100 and 100a having a processor may be a program for causing master ECUs 100 and 100a to execute, for example, the following predetermined update management process. The predetermined update management process includes an update right information receiving step for receiving update right information transmitted from an external tool connected to the diagnostic port via the diagnostic port and indicating the right of the external tool, and an update right information receiving step A verification step of verifying the update authority information received in the update message receiving step of receiving an update message transmitted from the external tool via the diagnostic port, and when the update message is received in the update message receiving step, When the verification in the verification step is successful and the update authority information indicates that the transmission of the update message is within the authority range of the external tool, the update message is transferred to a bus for communication with the ECU, When the verification in the verification step fails, or when the update message is sent by an external tool When the update authority information does not indicate that it is within the limited range, and a transfer control step of inhibiting the transfer.

  (16) The master ECU and the other ECUs in the above embodiment are devices including, for example, a digital circuit such as a processor and a memory, an analog circuit, a communication circuit, and the like. However, a hard disk device, a display, a keyboard, and a mouse Etc. may be included. Instead of the control program stored in the memory being executed by the processor to realize the function in software, the function may be realized by dedicated hardware (digital circuit or the like).

  (17) A part or all of the components constituting each device in the above embodiment may be constituted by one system LSI (Large Scale Integration: large scale integrated circuit). The system LSI is a super-multifunctional LSI manufactured by integrating a plurality of components on one chip, and specifically, is a computer system including a microprocessor, a ROM, a RAM, and the like. . The RAM stores a computer program. When the microprocessor operates according to the computer program, the system LSI achieves its function. In addition, each unit of the constituent elements constituting each of the above devices may be individually formed into one chip, or may be formed into one chip so as to include a part or the whole. Although the system LSI is used here, it may be called an IC, an LSI, a super LSI, or an ultra LSI depending on the degree of integration. Further, the method of circuit integration is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor. After manufacturing the LSI, an FPGA that can be programmed or a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used. Furthermore, if an integrated circuit technology that replaces the LSI appears due to the progress of the semiconductor technology or another derivative technology, the functional blocks may be integrated using the technology. Application of biotechnology and the like are possible.

  (18) A part or all of the constituent elements constituting each of the above devices may be constituted by an IC card or a single module that is detachable from each device. The IC card or the module is a computer system including a microprocessor, a ROM, a RAM, and the like. The IC card or the module may include the above-mentioned super multifunctional LSI. When the microprocessor operates according to the computer program, the IC card or the module achieves its function. This IC card or this module may have tamper resistance.

  (19) One aspect of the present invention may be an update management method such as the above-described shared key update sequence. Further, these methods may be a computer program that is realized by a computer, or may be a digital signal formed by the computer program. Further, as one embodiment of the present invention, a computer-readable recording medium for reading the computer program or the digital signal, for example, a flexible disk, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, and a BD (Blu-ray (registered trademark) Disc), semiconductor memory, or the like. Further, the digital signal may be recorded on these recording media. In one embodiment of the present invention, the computer program or the digital signal may be transmitted via an electric communication line, a wireless or wired communication line, a network represented by the Internet, a data broadcast, or the like. One embodiment of the present invention is a computer system including a microprocessor and a memory, wherein the memory stores the computer program, and the microprocessor operates according to the computer program. . Further, the program or the digital signal is recorded on the recording medium and transferred, or the program or the digital signal is transferred via the network or the like, so that it is implemented by another independent computer system. You may do it.

  (20) A mode realized by arbitrarily combining the components and functions described in the above-described embodiment and the above-described modified examples is also included in the scope of the present invention.

  INDUSTRIAL APPLICABILITY The present invention can be used to manage the update of firmware and the like of an ECU from an external tool in an in-vehicle network and reduce the risk of unauthorized rewriting and the like.

10, 10a In-vehicle network system 20 Key issuing organization 21 Maker 30, 30a, 30b External tool 35 Server 101 Transmitter / receiver 102, 402 Key holding unit 103 Judging unit 104 Level information holding unit 110, 410 Frame processing unit 120, 420 Frame generation unit 130,430 Receiving ID judging unit 140,440 Receiving ID list holding unit 150,450 Frame interpreting unit 160,460 Frame transmitting / receiving unit 180 Time information acquiring unit 190 Key update confirming unit 200 Head unit 300 Gateway 310 Engine 320 Brake 330 Door opening / closing sensor 340 Window opening / closing sensor 350 Airbag 470 Data acquisition unit 500a to 500d Bus 600 Diagnostic port 800 Storage battery

Claims (12)

An update management method executed by an update management device in an in-vehicle network system,
The in-vehicle network system includes a plurality of electronic control units that communicate via a network, an external tool is connected,
The update management device,
One electronic unit of the plurality of electronic units;
Holding a shared key used for transmitting a first session key for encryption processing between the update management device and an electronic control unit other than the update management device, and an expiration date of the shared key;
The update management method includes:
Verify the update authority information indicating the authority of the external tool,
When the verification of the update authority information is successful, and the update message instructing the update of the shared key is received from the external tool, the transmission of the update message by the external tool is within the authority range of the external tool. Is determined whether or not
(I) when it is determined that the update authority information indicates that the transmission of the update message by the external tool is within the authority range of the external tool, the update message is transferred to the network;
(Ii) when it is determined that the update authority information does not indicate that the transmission of the update message by the external tool is within the authority range of the external tool, the transfer is suppressed;
Determining whether the current time is within the expiration date, and transmitting an alert message urging the shared key to be updated when a predetermined time before the expiration date or when the expiration date has passed; . The plurality of electronic control units communicate according to a Controller Area Network (CAN) protocol;
The update management method according to claim 1, wherein the external tool transmits the update message according to a CAN protocol. The determination as to whether the transmission of the update message from the external tool is within the authority range of the external tool is made based on the message ID of the update message. When it is determined that the update authority information indicates that the update authority information is within the authority range, the update is performed on the electronic control unit that is determined to receive the update message having the message ID. Update management method described. The update authority information specifies one or more function types among the plurality of function types for classification of the electronic control unit, and the electronic control unit classifies the electronic control unit into one of the specified one or more function types. Represents that the external tool has authority to cause the control unit to perform the update,
Based on the message ID of the update message, a function type of the electronic control unit determined to receive the message ID matches one of one or more function types specified by the update authority information. The update management method according to claim 3, wherein the determination is performed by determining whether to perform the update. The update authority information indicates one level of a plurality of levels for specifying one or a plurality of the function types, and a relatively high level indicates one or a plurality of levels specified by a relatively low level. The update management method according to claim 4, wherein a plurality of function types including the function types are specified. The update management method according to claim 1, wherein transfer of the update message to the network is suppressed when a state of a vehicle equipped with the on-vehicle network system is not a predetermined state. The update management method according to claim 1, wherein transfer of the update message to the network is suppressed when a battery that supplies power to each electronic control unit in the in-vehicle network system does not have a predetermined remaining battery level. The update according to claim 1, wherein (i) transmitting identification information for identifying the in-vehicle network system among a plurality of in-vehicle network systems, and (ii) result information indicating a processing result of the update message to the external tool. Management method. The update management method according to claim 1, wherein the update of the data held by the electronic control unit, which is indicated by the update message, is an update of firmware of the electronic control unit. Sending the alert message to an electronic control unit controlling a display;
The update management method according to claim 1. An update management device in an in-vehicle network system,
The in-vehicle network system includes a plurality of electronic control units that communicate via a network, an external tool is connected,
The update management device,
One electronic unit of the plurality of electronic units;
A shared key used for transmitting a first session key for encryption processing between the update management device and an electronic control unit other than the update management device, and a holding unit for holding an expiration date of the shared key;
Update authority information indicating the authority of the external tool from the external tool, and a receiving unit that receives an update message instructing the update of the shared key,
A verification unit that verifies the update authority information received by the reception unit,
When the verification by the verification unit is successful and the update message is received by the reception unit, (i) when the update authority information indicates that the transmission of the update message is within the authority range of the external tool, A transfer unit that transfers the update message to the network, and (ii) when the update authority information does not indicate that the transmission of the update message is within the authority range of the external tool, suppresses the transfer;
A determining unit for determining whether the current time is within the expiration date,
A transmission unit that transmits an alert message urging the shared key to be updated when the expiration date has passed a predetermined time or when the expiration date has passed. A control program for controlling an update management device in an in-vehicle network system,
The in-vehicle network system includes a plurality of electronic control units that communicate via a network, an external tool is connected,
The update management device,
The electronic control unit of one of the plurality of electronic control units,
Holding a shared key used for transmitting a first session key for encryption processing between the update management device and an electronic control unit other than the update management device, and an expiration date of the shared key;
The control program includes:
Verify the update authority information indicating the authority of the external tool,
When the verification of the update authority information is successful, and when an update message instructing the update of the shared key is received from the external tool, the transmission of the update message by the external tool is within the authority range of the external tool. Is determined whether or not
(I) when it is determined that the update authority information indicates that the transmission of the update message by the external tool is within the authority range of the external tool, the update message is transferred to the network;
(Ii) when it is determined that the update authority information does not indicate that the transmission of the update message by the external tool is within the authority range of the external tool, the transfer is suppressed;
A control program that determines whether a current time is within the expiration date, and transmits an alert message urging the update of the shared key when a predetermined time before the expiration date or when the expiration date has passed.

Images