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

Abstract

To provide an update management method for letting an external tool to update common keys etc., in all ECUs while reducing a risk of illegal rewriting of all the ECUs.SOLUTION: An update management method comprises: performing verification using a certificate of an external device; determining, when the verification by the certificate is successful and the latest message indicative of update of firmware of a plurality of electronic control units other than an update management device is received from the external device, whether or not a transmission of the update message is within a range of an authority of the external device; and transferring the update message to a network (i) when it is determined that the transmission of the update message by the external device is within the range of the authority of the external device, or stopping the transfer (ii) when it is determined that the transmission of the update message by the external device is not within the range of the authority of the external device.SELECTED DRAWING: Figure 12

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 an in-vehicle network system.

In recent years, a large number of devices called electronic control units (ECUs) are arranged in a system in an automobile. The network connecting these ECUs is called an in-vehicle network. There are many standards for in-vehicle networks. Among them, the standard called CAN (Controller Area Network) defined by ISO11898-1 is the mainstream. In CAN, the communication path is composed of two buses, and the ECU connected to the buses is called a node. Each node connected to the bus sends and receives a message called a frame. In CAN, there is no identifier that points to the destination or source, the transmitting node attaches an ID (called a message ID) to each frame and transmits (that is, sends a signal to the bus), and each receiving node is predetermined. Receives only the message ID (that is, reads the signal from the bus). Further, the CSMA / CA (Carrier Sense Multiple Access / Collision Avoidance) method is adopted, and when a plurality of nodes are simultaneously transmitted, arbitration is performed by the message ID, and the frame having a small message ID value is preferentially transmitted. Further, in the in-vehicle network, there is a port (hereinafter referred to as "diagnosis port") which is an interface for communicating with an external tool (for example, an external device such as a failure diagnosis tool) called OBD2 (On-Board Diagnostics 2). It is used for ECU diagnosis. Recently, not only diagnosis but also rewriting of ECU firmware using the diagnosis port has become possible. In addition, external tools that can be connected to the diagnostic port are available at low prices, and the number of external tools that can be used by general users rather than specialists is increasing.

Therefore, 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 to prevent unauthorized firmware rewriting via the diagnostic port in this way, the identification code is embedded in the firmware update request message sent by the external tool, and if the identification code matches the registration code, the firmware is updated. There is a method of permitting (see Patent Document 1).

Japanese Unexamined Patent Publication No. 2013-141948

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

The present invention reduces the risk that the firmware of all ECUs is illegally rewritten when confidential information given to an external tool is leaked, and updates management for causing an external tool to update data in the ECU such as firmware. Provide a method. The present invention also provides an update management device for reducing risk and causing an external tool to update data in the ECU, and a control program for this update management device.

The update management method according to one aspect of the present invention for solving the above problems is an update management method executed by an update management device in an in-vehicle network system, and the in-vehicle network system communicates via a network. The update management device includes a plurality of electronic control units, and the update management device is one of the plurality of electronic control units and can communicate with an external device. The update management method is a certification of the external device. When the verification using the document is performed, the verification of the certificate is successful, and an update message instructing the update of the firmware of the plurality of electronic control units other than the update management device is received from the external device. It is determined whether or not the transmission of the update message by the external device is within the authority range of the external device, and (i) the transmission of the update message by the external device is within the authority range of the external device. When it is determined, the update message is transferred to the network, and (ii) when it is determined that the transmission of the update message by the external device is not within the authority range of the external device, the transfer is suppressed.

Further, in order to solve the above problems, the update management device according to one aspect of the present invention is an update management device in an in-vehicle network system, and the in-vehicle network system is a plurality of electronic control units that communicate via a network. The update management device is one of the plurality of electronic control units, is capable of communicating with an external device, and updates the certificate and firmware of the external device from the external device. The receiving unit that receives the update message instructing the above, the verification unit that verifies the certificate received by the receiving unit, and the verification unit that verifies the certificate successfully, and the receiving unit receives the update message. In the case, (i) when it indicates that the transmission of the update message is within the authority range of the external device, the update message is transferred to the network, and (ii) the transmission of the update message is the authority of the external device. When it is not within the range, a transfer unit for suppressing the transfer is provided.

Further, in order to solve the above problems, the program according to one aspect of the present invention is a control program for controlling an update management device in an in-vehicle network system, and the in-vehicle network system communicates via a network. A plurality of electronic control units are provided, the update management device is one of the plurality of electronic control units, the electronic control unit is capable of communicating with an external device, and the control program is a certification of the external device. When the verification using the document is performed, the verification of the certificate is successful, and the update message instructing the firmware update is received from the external device, the transmission of the update message by the external device is the external device. It is determined whether or not it is within the authority range of the device, and (i) when it is determined that the transmission of the update message by the external device is within the authority range of the external device, the update message is transferred to the network. Then, (ii) when it is determined that the transmission of the update message by the external device is not within the authority range of the external device, the transfer is suppressed.

The update management method according to one aspect of the present invention for solving the above problems is an update management method executed by an update management device in an in-vehicle network system, and the in-vehicle network system communicates via a network. A plurality of electronic control units are provided, an external tool is connected, and the update management device is one of the plurality of electronic units, and includes the update management device and an electronic control unit other than the update management device. The shared key used for transmitting the first session key for encryption processing between the two, and the expiration date of the shared key are retained, and the update management method verifies the update authority information indicating the authority of the external tool. When the verification of the update authority information is successful and 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 the authority of the external tool. When it is determined whether or not it is within the range, and (i) 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 (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 and the current It is determined whether or not the time is within the expiration date, and when a certain time before the expiration date or the expiration date has passed, an alert message prompting the renewal of the shared key is transmitted.

Further, in order to solve the above problems, the update management device according to one aspect of the present invention is an update management device in an in-vehicle network system, and the in-vehicle network system is a plurality of electronic control units that communicate via a network. The update management device is one of the plurality of electronic units, and is an encryption process between the update management device and an electronic control unit other than the update management device. The shared key used for transmitting the first session key for the system, the holding unit that holds the expiration date of the shared key, the update authority information indicating the authority of the external tool from the external tool, and the shared key. The receiving unit that receives the update message instructing the update of the above, the verification unit that verifies the update authority information received by the receiving unit, and the verification unit succeeds in the verification, and the receiving unit sends the update message. When received, (i) when the update permission information indicates that the transmission of the update message is within the permission range of the external tool, the update message is forwarded to the network, and (ii) the update message. When the update authority information does not indicate that the transmission is within the authority range of the external tool, the transfer unit that suppresses the transfer, the determination unit that determines whether the current time is within the expiration date, and the determination unit. It is provided with a transmission unit that transmits an alert message prompting the update of the shared key when a certain time before the expiration date or when the expiration date has passed.

Further, in order to solve the above problems, the control program according to one aspect of the present invention is a control program for controlling an update management device in an in-vehicle network system, and the in-vehicle network system communicates via a network. A plurality of electronic control units to be performed are provided, an external tool is connected, and the update management device is the electronic control unit of one of the plurality of electronic control units, other than the update management device and the update management device. The shared key used for transmitting the first session key for encryption processing to and from the electronic control unit and the expiration date of the shared key are held, and the control program has update permission information indicating the permission 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 the external. When it is determined whether or not it is within the authority range of the tool, and (i) 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. When the update message is transferred to the network and (ii) 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. Then, it is determined whether or not the current time is within the expiration date, and when a certain time before the expiration date or the expiration date has passed, an alert message prompting the renewal of the shared key is transmitted.

In order to solve the above problems, the update management method according to one aspect of the present invention is 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. When the update authority information indicating the authority of the external tool is received and verified, and an update message instructing the update of the data held by one or more of the electronic control units is sent from the external tool. When the update authority information indicates that the verification is successful and 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 update authority information does not indicate that the transmission of the update message is within the authority range of the external tool, the one or more electronic devices are used. This is an update management method for suppressing the update corresponding to the update message by the control unit.

Further, in order to solve the above problems, the update management device according to one aspect of the present invention is one electronic control unit connected to a diagnostic port in an in-vehicle network system including a plurality of electronic control units that communicate via a bus. An update management device, which is transmitted from an external tool connected to the diagnostic port via the diagnostic port, update authority information indicating the authority of the external tool, and one or more electronic control units. When the receiving unit receives the update message instructing the update of the data held by the receiver, the verification unit verifies the update authority information received by the receiving unit, and the receiving unit receives the update message. When the update authority information indicates that the verification by the verification unit is successful and the transmission of the update message is within the authority range of the external tool, the update message is transferred to the bus and the verification is performed. An update management device including a transfer unit that suppresses the transfer when the verification by the 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. Is.

Further, in order to solve the above problems, the control program according to one aspect of the present invention is used as one electronic control unit connected to a diagnostic port in an in-vehicle network system including a plurality of electronic control units that communicate via a bus. , A control program for causing an update management device having a processor to execute a predetermined update management process, and the update management process is transmitted from an external tool connected to the diagnostic port via the diagnostic port. , The update authority information receiving step for receiving the update authority information indicating the authority of the external tool, the verification step for verifying the update authority information received in the update authority information receiving step, and the diagnostic port from the external tool. When the update message receiving step for receiving the update message instructing the update of the data held by the one or more electronic control units transmitted via the update message receiving step and the update message receiving step for receiving the update message are received. When the verification in the verification step is successful and the update permission information indicates that the transmission of the update message is within the permission range of the external tool, the update message is transferred to the bus, and the update message is transferred to the bus. When the verification in the verification step 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 control step for suppressing the transfer is included. It is a control program.

According to the present invention, it is possible to reduce the risk that the firmware of all ECUs is illegally rewritten when the confidential information given to the external tool is leaked, and to cause the external tool to update the data in the ECU.

FIG. 5 is an overall configuration diagram of an in-vehicle network system according to the first embodiment. It is a figure which shows the format of the data frame specified by the CAN protocol. It is a figure which shows the key issuing system which concerns on an ECU and an external tool. It is a figure which shows the structure of a public key certificate. It is a figure which shows the correspondence relationship between the level of the renewal authority information described in the public key certificate, and the function type of ECU. It is a figure which shows the shared key held by the ECU. It is a block diagram of the master ECU (update management apparatus) which concerns on Embodiment 1. FIG. It is a figure which shows the level information which concerns on Embodiment 1. FIG. It is a block diagram of an ECU. It is a figure which shows the reception ID list. It is a figure which shows the shared key update sequence which concerns on Embodiment 1 (following FIG. 12). It is a figure which shows the shared key update sequence which concerns on Embodiment 1 (continue from FIG. 11). FIG. 5 is an overall configuration diagram of an in-vehicle network system according to a second embodiment. It is a figure which shows the level information which concerns on Embodiment 2. It is a figure which shows the shared key update sequence which concerns on Embodiment 2 (following FIG. 16). It is a figure which shows the shared key update sequence which concerns on Embodiment 2 (continuation from FIG. 15). It is a block diagram of the master ECU (update management apparatus) which concerns on Embodiment 3. It is a figure which shows the information which associated with the shared key which concerns on Embodiment 3 and the expiration date and the like. It is a figure which shows an example of the screen which prompts the update of the shared key which concerns on Embodiment 3. It is a figure which shows the shared key update sequence which concerns on Embodiment 4 (following FIG. 21). It is a figure which shows the shared key update sequence which concerns on Embodiment 4 (continuation from FIG. 20). It is a figure which shows the log information which the server which concerns on Embodiment 4 holds.

The update management method according to one aspect of the present invention is an update management method executed by an update management device in an in-vehicle network system, and the in-vehicle network system includes a plurality of electronic control units that communicate via a network. , An external tool is connected, and 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. The shared key used for transmitting the first session key and the expiration date of the shared key are retained, and the update management method verifies the update authority information indicating the authority of the external tool, and obtains the update authority information. Whether or not the transmission of the update message by the external tool is within the authority range of the external tool when the verification is successful and the update message instructing the update of the shared key is received from the external tool. (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 and the current time is within the expiration date. It determines whether or not there is, and sends an alert message prompting the renewal of the shared key when the expiration date has passed or before the expiration date.

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

Further, the determination as to whether or not the transmission of the update message from the external tool is within the authority range of the external tool is determined based on the message ID of the update message, and the transmission of the update message is the external. When it is determined that the update authority information indicates that the tool is within the authority range, the update is executed for the electronic control unit defined to receive the update message having the message ID. May be.

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

Further, the update authority information indicates one level out of a plurality of levels for specifying one or a plurality of the function types, and a relatively high level is one or a relatively low level specified. It is also possible to specify a plurality of function types including a plurality of function types.

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 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 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 the 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 the display.

Further, in order to solve the above problems, the update management device according to one aspect of the present invention is an update management device in an in-vehicle network system, and the in-vehicle network system is a plurality of electronic control units that communicate via a network. The update management device is one of the plurality of electronic units, and is an encryption process between the update management device and an electronic control unit other than the update management device. The shared key used for transmitting the first session key for the system, the holding unit that holds the expiration date of the shared key, the update authority information indicating the authority of the external tool from the external tool, and the shared key. The receiving unit that receives the update message instructing the update of the above, the verification unit that verifies the update authority information received by the receiving unit, and the verification unit succeeds in the verification, and the receiving unit sends the update message. When received, (i) when the update permission information indicates that the transmission of the update message is within the permission range of the external tool, the update message is forwarded to the network, and (ii) the update message. When the update authority information does not indicate that the transmission is within the authority range of the external tool, the transfer unit that suppresses the transfer, the determination unit that determines whether the current time is within the expiration date, and the determination unit. It is provided with a transmission unit that transmits an alert message prompting the update of the shared key when a certain time before the expiration date or when the expiration date has passed.

Further, in order to solve the above problems, the control program according to one aspect of the present invention is a control program for controlling an update management device in an in-vehicle network system, and the in-vehicle network system communicates via a network. A plurality of electronic control units to be performed are provided, an external tool is connected, and the update management device is the electronic control unit of one of the plurality of electronic control units, other than the update management device and the update management device. The shared key used for transmitting the first session key for encryption processing to and from the electronic control unit and the expiration date of the shared key are held, and the control program has update permission information indicating the permission 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 the external. When it is determined whether or not it is within the authority range of the tool, and (i) 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. When the update message is transferred to the network and (ii) 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. Then, it is determined whether or not the current time is within the expiration date, and when a certain time before the expiration date or the expiration date has passed, an alert message prompting the renewal of the shared key is transmitted.

The update management method according to one aspect of the present invention is 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. The verification is successful when the update permission information indicating the permission is received and verified, and an update message instructing the update of the data held by the one or more electronic control units is sent from the external tool. Moreover, 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. , 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 update message by the one or more electronic control units is sent. This is an update management method that suppresses the corresponding update. Thereby, the authority to send the update message instructing the update of the data in the ECU can be set differently for each external tool according to the verifiable update authority information. Then, only an external tool having the authority to transmit the update message of the data in some ECUs in the in-vehicle network system can update the data in some ECUs. Further, even if confidential information is leaked from an external tool having the authority to transmit a data update message in a part of the ECU, the ECUs other than the part of the ECU are not illegally rewritten. Therefore, it is possible to reduce the risk that the firmware and the like of all the ECUs in the in-vehicle network are illegally rewritten, and have an external tool update the data in the ECU.

Further, the plurality of electronic control units may communicate via the bus according to the Controller Area Network (CAN) protocol, and the external tool may transmit the update message according to the CAN protocol. As a result, the data in the ECU can be updated by an external tool having appropriate authority in the in-vehicle network system according to CAN.

Further, when the update message is transmitted from the external tool, does the update authority information indicate that the transmission of the update message is within the authority range of the external tool based on the message ID of the update message? When it is determined whether or not the update message is transmitted and 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, it is defined to receive the update message having the message ID. The update may be executed by the electronic control unit. As a result, it is possible to distinguish whether or not the ECU is the target of the update instruction in the update message by the ID (message ID) of the frame of the CAN. Therefore, the update authority for a specific one or a plurality of ECUs can be distinguished from the update authority for another one or a plurality of ECUs. It is possible to allow the update only to the appropriate external tools that it has.

Further, the update authority information specifies one or a plurality of function types among a plurality of function types for classification of the electronic control unit, and is classified into one of the specified one or a plurality of the specified function types. Indicates that the external tool has the authority to cause the electronic control unit to perform the update, and when the update message is transmitted from the external tool, the message ID is received based on the message ID of the update message. The determination is made by determining whether or not the function type of the electronic control unit specified to be performed matches any one or a plurality of function types specified by the update authority information. May be. As a result, it is possible to perform an operation in which the authority for updating is distinguished and certified as an external tool for each function type that classifies the ECU in terms of function. This certification is performed, for example, by granting verifiable update authority information.

Further, the update authority information indicates one level out of a plurality of levels for specifying one or a plurality of the function types, and a relatively high level is one or a relatively low level specified. It is also possible to specify a plurality of function types including a plurality of function types. This makes it possible to have different levels of update authority for each external tool. For example, even if confidential information about an external tool with a low level of authority is leaked, an ECU other than the function type of the ECU that can be updated according to the level (that is, an ECU that can be updated by an external tool with a high level of authority). ) Cannot be rewritten illegally.

Further, the update management device, which is one of the electronic control units, receives the update authority information from the external tool connected to the diagnostic port connected to the update management device, performs the verification, and performs the verification from the external tool. When the update message is sent, the update message is received, and when the update message is received, the verification is successful and the transmission of the update message is within the permission range of the external tool. When the update message is forwarded to the bus and 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 update message is described. It may be possible to suppress the transfer. As a result, the update management device (master ECU) controls whether or not to transfer the update message to another ECU, so that the other ECU can omit the inspection related to the authority of the external tool.

Further, if the update message is not subjected to a predetermined encryption process using the 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. Is performed by receiving the public key certificate related to the public key of the external tool that describes the update authority information, and when the verification is successful, the external tool responds to the update message when transmitting the update message. The session key used for performing the predetermined encryption process may be encrypted with the public key of the external tool and transmitted to the external tool. As a result, the authority to update external tools can be certified by issuing a public key certificate. In addition, the public key in the public key certificate can be used to ensure security related to the communication content by an external tool.

Further, the update management device suppresses the transfer of the update message to the bus when the update message is transmitted from the external tool and the state of the vehicle equipped with the in-vehicle network system is not a predetermined state. It may be a thing. As a result, if, for example, a stopped state, an engine stopped state, or the like is set as a predetermined state, the data in the ECU is updated in, for example, a stopped state in which the load of the ECU related to running is reduced and the bus traffic is relatively reduced. Therefore, for example, the possibility that a problem may occur in the update can be reduced.

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

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

Further, the warning information prompting the update of the shared key may be output before a certain period of the expiration date of the shared key. As a result, it is possible to prompt the key renewal before the expiration date of the shared key, and it is possible to reduce the risk that the shared key will continue to be used after the expiration date.

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

Further, the external tool may transmit the result information and the identification information to the server. This makes it possible for the server to manage the update result of 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. This makes it possible to flexibly set the authority for updating the ECU firmware for each external tool.

Further, the update management device according to one aspect of the present invention is an update management device that is one electronic control unit connected to a diagnostic port in an in-vehicle network system including a plurality of electronic control units that communicate via a bus. , Update authority information indicating the authority of the external tool transmitted from the external tool connected to the diagnostic port via the diagnostic port, and update of data held by one or more of the electronic control units. The receiving unit that receives the update message to be instructed, the verification unit that verifies the update authority information received by the receiving unit, and the verification unit that verifies the update message when the receiving unit receives the update message. Was 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 message was transferred to the bus, and the verification by the verification unit failed. When, 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 update management device includes a transfer unit that suppresses the transfer. As a result, when the confidential information given to the external tool is leaked, the risk of unauthorized rewriting of the firmware or the like in all the ECUs can be reduced, and the external tool can update the data in the ECU.

Further, the control program according to one aspect of the present invention is an update management device having a processor as one electronic control unit connected to a diagnostic port in an in-vehicle network system including a plurality of electronic control units that communicate via a bus. Is a control program for executing a predetermined update management process, and the update management process obtains the authority of the external tool transmitted from the external tool connected to the diagnostic port via the diagnostic port. An update authority information receiving step for receiving the indicated update authority information, a verification step for verifying the update authority information received in the update authority information receiving step, and transmission from the external tool via the diagnostic port 1 When the update message receiving step for receiving the update message instructing the update of the data held by the electronic control unit or the plurality of electronic control units is received and the update message is received in the update message receiving step, the said in the verification step. When the verification is successful and the update permission information indicates that the transmission of the update message is within the permission range of the external tool, the update message is forwarded to the bus and the verification in the verification step is performed. It is a control program including a transfer control step that suppresses the transfer when it 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. By installing this program in the update management device and letting the processor execute it, the risk of unauthorized rewriting of the firmware in all ECUs when confidential information given to external tools is leaked is reduced, and the external It becomes possible to make the tool update the data in the ECU.

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

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 shows a specific example of the present invention. Therefore, the numerical values, the components, the arrangement and connection form of the components, the steps (processes), the order of the 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, the components not described in the independent claims are components that can be arbitrarily added. Further, each figure is a schematic view and is not necessarily exactly 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, when the external tool is connected to the diagnostic port of the in-vehicle network system 10, the master ECU 100 authenticates the external tool 30 and the external tool 30 is satisfied only when a certain condition is satisfied. Shows an example of permitting the update of ECU data (firmware, etc.).

[1.1 Overall configuration of in-vehicle network system 10]
FIG. 1 is a diagram showing an overall configuration of the vehicle-mounted network system 10 according to the first embodiment. In addition to the in-vehicle network system 10, the external tool 30 is shown in the figure. The external tool 30 represents, for example, individual various external tools (for example, external tools 30a and 30b described later) manufactured by a business operator or the like that manufactures and maintains various ECUs. The in-vehicle network system 10 is an example of a network communication system that communicates according to the CAN protocol, and is a network communication system in an automobile (vehicle) equipped with various devices such as a control device and a sensor. The in-vehicle network system 10 includes a plurality of devices (nodes) that perform communication related to frames via a bus according to the 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. It is configured to include each node connected to a bus such as an ECU such as ~ 400f. The in-vehicle network system 10 may include a number of ECUs in addition to the master ECU 100 and the ECUs 400a to 400f, but here, for convenience, the master ECU 100 and the ECUs 400a to 400f will be described. 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, 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. A computer program is configured by combining a plurality of instruction codes indicating instructions to a processor in order to achieve a predetermined function.

The diagnostic port 600 is a port for connecting an external tool 30 when performing maintenance on the ECU constituting 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, an OBD2 compliant connector. By connecting to the diagnostic port 600, the external tool 30 can transmit a frame according to the CAN protocol to the in-vehicle network system 10. For example, the external tool 30 transmits a message including a predetermined range of message IDs in the in-vehicle network system 10, such as an update message for updating the firmware of the ECU or a diagnostic message for diagnosing an ECU failure. Can be sent. Here, in particular, pay attention to the fact that the external tool sends an update message (that is, a frame for update request) including a predetermined range of message IDs for updating each of the ECU firmware and the shared key. I will explain.

The master ECU 100 authenticates the external tool 30 and permits the update message from the external tool to be updated based on the update authority information described in the certificate of the external tool 30 (public key certificate described later). It is a kind of ECU as an update management device having a role of determining whether or not it is. Further, the master ECU 100 is used for transmitting a session key for encryption processing related to the communication content in the frame between each of the plurality of ECUs in the in-vehicle network system 10 and one or more ECUs other than the own device. 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 opening / closing sensor 330, the window opening / closing sensor 340, the airbag 350, and the head unit 200, respectively. Each of the ECUs 400a to 400e acquires the state of the connected device (engine 310, etc.) and periodically transmits a frame indicating the state to the network (that is, the 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) or the like of an automobile, and can notify the 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 the 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. Has the function of It is also possible to switch whether to transfer the received frame for each connected bus. The gateway 300 is a kind of ECU.

In the in-vehicle network system 10, each ECU including the master ECU 400 transfers and receives frames via the bus according to the CAN protocol. The frames in the CAN protocol include data frames, remote frames, overload frames, and error frames, but for convenience of explanation, the data frames will be mainly described here.

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

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

The SOF is composed of 1 bit dominant. The idle state of the bus is recessive, and the SOF changes the bus to dominant to notify the start of frame transmission.

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

The RTR is a value for distinguishing between a data frame and a remote frame, and is composed of a dominant 1 bit in the data frame.

Both IDE and "r" are composed of dominant 1 bit.

The DLC is composed of 4 bits and is a value indicating the length of the data field. The IDE, "r" and DLC are collectively referred to as 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 in 8-bit units. The specifications of the data to be transmitted are not specified by the CAN protocol, but are specified by the in-vehicle network system 10. Therefore, the specifications depend on the vehicle type, manufacturer (manufacturer), and the like.

The CRC sequence consists 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 of recessive. The CRC sequence and CRC delimiter are collectively referred to as a CRC field.

The ACK slot is composed of 1 bit. The transmitting node makes the ACK slot recessive and transmits. The receiving node transmits the ACK slot as a dominant if the CRC sequence is normally received. Since dominant is prioritized over recessive, if the ACK slot is dominant after transmission, the transmitting node can confirm that any receiving node has succeeded in receiving.

The ACK delimiter is a delimiter indicating the end of ACK composed of 1 bit recessive.

The EOF is composed of 7 bits of recessive and indicates the end of the data frame.

[1.3 Key Issuing System]
FIG. 3 is a diagram showing a key issuing system related to the above-mentioned ECU and external tools. The key issuing institution 20 distributes the public key certificate 40a to 40c, the private key 50a to 50c, and the shared key 60 to the manufacturer 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 and the like. The manufacturer 21 is, for example, an OEM manufacturer (Original Equipment Manufacturer), EC.
U vendor, etc. The public key certificate describing the public key and the private key are used in the public key infrastructure (PKI: Public Key Infrastructure), and the public key and the private key are in elliptical cryptography and RSA.
It is a key pair such as encryption. The private key and public key certificate are used for authentication between the master ECU 100 and the external tools 30a to 30b. The shared key 60 represents an individual 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 a frame. .. As the encryption process related to the frame, in addition to encrypting and decrypting the contents of the data field of the frame, for example, on the transmitting side of the frame, a message authentication code (MAC) is added to the data field of the frame.
Is generated, added, and transmitted, and the receiving side verifies the MAC. This MAC makes it possible to detect falsification of data. The session key is used, for example, to generate a MAC.

In the example of FIG. 3, the public key certificate 40a and the private key 50a are written in the external tool 30a, the public key certificate 40b and the private key 50b are written in the external tool 30b, and the master ECU 20 is written. It is shown that the public key certificate 40c, the private key 50c, and the shared key 60 are written, and the shared key 60 is written in the ECUs 400a to 400f. In the example of FIG. 3, the level of the renewal authority information described in the public key certificate 40a is 3, and the level of the renewal 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 the public key certificate 40a issued or distributed by the key issuing institution 20 to be written in 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 the version, issuer, start and end of validity period, certificate identification information (ID), public key, renewal authority information (level), and signatures for these. It is composed. The signature is given by the key issuing institution 20 or a certificate authority such as a portal server. Therefore, the master ECU 100 can authenticate the external tool 30 by acquiring the public key certificate from the external tool 30 and verifying the signature.

The update authority information in the public key certificate is authorized to send an update message instructing the external tool 30 (external tools 30a, 30b, etc.) to update the data in the ECU for which type of ECU. It is information indicating whether or not the authority is specified, and specifically, indicates one of the levels divided into a plurality of stages regarding the authority. Therefore, the level of authority authorized by the certificate authority or the like, which is the signing entity, for the external tool 30 is indicated in the update authority information.

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

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

First, the functional types of the ECU will be described. Drive system functions are functions related to the running of a vehicle, such as control of an engine, a motor, 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 system function is a function related to control of vehicle behavior such as "turning" and "stopping" such as braking and steering. For example, the ECU 400b related to the brake 320 corresponds to the function type of the chassis system function. Body functions are functions related to the control of vehicle equipment such as door locks, air conditioners, lights, and blinkers. 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. In addition, the safety / 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 maintaining function, a collision prevention function, and an airbag. The ECU 400e related to the airbag 350 corresponds to the function type of the safety / comfort function. ITS (Intelligent Transport Systems) functions are ET
This function is compatible with intelligent transportation systems such as C (Electronic Toll Collection System). The telematics function is a function corresponding to a service using mobile communication. Infotainment functions are entertainment functions related to car navigation, audio, and the like. For example, the ECU 400f related to the head unit 200 corresponds to the function type of the infotainment system function.

The level of authority as the content of the update authority information certified by the certificate authority, etc., which is the signing entity of the public key certificate, is one of the plurality of function types described above based on the correspondence relationship illustrated in FIG. Or specify multiple function types. Then, the external tool to which the public key certificate is given is assigned to the ECU classified into one or a plurality of function types specified by the level of the update authority information, and the data (firmware, sharing) in the ECU. It is certified that it has the authority to update the key), that is, the authority to send an update message for updating the firmware or shared key.

According to the example of FIG. 5, a public key certificate containing renewal authority information indicating one of the four levels from the highest level 4 to the lowest level 1 for renewal authority is given to each external tool. (That is, it will be written). Each external tool may have different functions, configurations, etc. Therefore, 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 various other circumstances are taken into consideration for each external tool. Update authority information can be defined. Note that FIG. 5 is only an example of the level, and different from this example, the number of levels, the correspondence between the level and the function type, and the like may be defined. Further, a correspondence relationship may be defined such that each of a plurality of levels (for example, level 4 and level 2) corresponds to the same one function type. Further, the classification of the function type can be determined so as to be different from the example of FIG. Here, in the update authority information, a relatively high level specifies a plurality of function types including one or a plurality of function types specified by a lower level, that is, a high level includes a low level authority. Explain as what to do. However, the correspondence between the levels and the function types may be defined so that there is no inclusion relationship between the authority levels. However, when the level of authority authorized for external tools is relatively low, only some ECUs that are not related to vehicle running, behavior, etc. are allowed to update data, and other ECUs are allowed. It is useful not to update the data in. Specifically, if the level of authority granted to the external tool (that is, the level that is the content of the update authority information) is 3, the external tool has all levels of level 3 or lower (that is, levels 1 to 3). ) It is permitted to send an update message to each ECU classified into the corresponding function type to update the data in the ECU.

In the in-vehicle network system 10, when the external tool 30 is connected to the diagnostic port 600, the master ECU 100 receives the update authority information that determines the authority level from the external tool 30, and based on this update authority information, the external tool For the update message transmitted by 30, a determination is made as to whether or not to allow the update. In this determination, the master ECU 100 refers to the level information 1040 determined based on the correspondence between the above-mentioned level and the function type (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 shared keys held by the master ECU 100 and the ECUs 400a to 400f. Specifically, as shown in the figure, the above-mentioned shared key 60 includes a shared key 60a shared by all ECUs, a shared key 60b shared by the ECU 400f and the master ECU 100, and ECUs 400c, 400d and the master ECU 100. There are a shared key 60c shared by the ECU 400a, 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. The master ECU 100 holds a transmission / reception unit 101, a key holding unit 102, a determination unit 103, a level information holding unit 104, a frame transmission / reception unit 160, a frame interpretation unit 150, a reception ID determination unit 130, and a reception ID list. A unit 140, a frame processing unit 110, and a frame generation unit 120 are included. Each of these components is a functional component, and each function is realized by a communication circuit in the 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 and the public key certificate (public key certificate 40a) from the external tool 30 for authentication between the master ECU 100 and the external tools 30 (external tools 30a and 30b). Alternatively, the public key certificate 40b) is received. Further, the transmission / reception unit 101 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 also transmits the update result by the update message.

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

The frame transmission / reception unit 160 transmits / receives a frame according to the CAN protocol to the bus 500b. That is, the frame from the ECUs 400a to 400f is received, and the frame is transmitted to the ECUs 400a to 400f. Frames are received one bit at a time from the bus 500b and transmitted to the frame interpretation unit 150. Further, the content of the frame notified by the frame generation unit 120 is transmitted bit by bit to the bus 500b.

The frame interpretation unit 150 receives the frame value from the frame transmission / reception unit 160 and interprets it so as to map it to each field in the frame format defined by the CAN protocol. The frame interpretation unit 150 transfers the value (message ID) determined to be the ID field to the reception ID determination unit 130. Depending on 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). To discontinue the interpretation as). If it is determined that the frame does not conform to the CAN protocol, the frame generation unit 120 is notified to transmit an error frame. Further, when the frame interpreting unit 150 receives an error frame, that is, interprets that the value in the received frame is an error frame, the frame interpreting unit 150 discards the frame after that, that is, stops interpreting the frame. To 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 list of message IDs held by the reception ID list holding unit 140. Determine whether or not to do so. The reception ID determination unit 130 notifies the frame interpretation unit 150 of this determination result. Further, the reception ID determination unit 130, like the frame interpretation unit 150, also determines whether or not the message ID belongs to the frame to be received to the determination unit 103, and notifies the determination result 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 configures 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 the error frame. Further, when a frame generation instruction is received from the determination unit 103, the data is encrypted (for example, a MAC corresponding to a session key or the like is added) to form a frame, and the frame transmission / reception unit 160 is notified and transmitted. Let me.

The determination unit 103 authenticates the external tool 30 by verifying the public key certificate including the update authority information received from the external tool 30. When the determination unit 103 succeeds in verifying the public key certificate received from the external tool 30, the external tool 30 is successfully authenticated. The fact that the determination unit 103 succeeded in verifying the public key certificate also means that the update authority information was successfully verified. When the update message is received by the transmission / reception unit 101, the determination unit 103 determines that the verification of the update authority information is successful 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 is indicated, it is determined whether or not to allow 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 determined in light of the level information 1040 (described later) held by the level information holding unit 104. It is performed by determining whether or not the correspondence is appropriate. When 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, when it is determined that the update message is permitted). Instructs the frame generation unit 120 to generate a new update message, which is a frame corresponding to the (original) update message, for transfer to another ECU (that is, for transmission to the bus 500b). The new update message generated by the frame generation unit 120 for transfer 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, and the data is encrypted. When the data is applied, the encryption processing applied to the data (for example, the MAC added to the data) is different. The update message generated by the frame generation unit 120 is sent 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 it is determined that the update message from the external tool 30 is a permitted update message, the update message is sent by the master ECU 100. Will be transferred to the ECU (that is, to the bus 500b). Further, when the determination unit 103 determines 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 predetermined processing according to the frame data received from the bus 500b. When, for example, the frame processing unit 110 receives a frame indicating the update result in each ECU by the update message from the bus 500b, the frame processing unit 110 generates a message (frame) containing the update result to be generated and the transmission / reception unit 101 Is sent 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 showing an example of the level information 1040 held by the level information holding unit 104.

The level information 1040 is information in which the message ID 1041 and the level 1042 are associated with each other, and is used in the determination unit 103 to determine whether or not to allow the update message from the external tool 30.

Message ID 1041 indicates the message ID of the update message that can be transmitted from the external tool 30. Here, "0x100" to "0x104" are defined as the message ID for the update message for updating the shared key held by the ECU, and "0x100" to "0x104" are defined as the message ID for the update message for updating the firmware of the ECU. It will be described assuming that "0x200" to "0x206" are defined.

Level 1042 indicates the level of authority required to send an update message with the corresponding message ID. This level corresponds to the level as the content of the update authority information. For example, if the level value indicated by the renewal 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 level 1042, it is associated with the value of level 1042. The external tool 30 has the authority to send the update message of the received message ID 1041. On the contrary, if the level value indicated by the update authority information described in the public key certificate of the external tool 30 is a value indicating an authority lower than the value of level 1042, the message ID 1041 associated with the level 1042 The external tool 30 does not have the authority to send the update message.

The message ID “0x100” shown 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 the highest value of 4. This 4 is the value of the highest level (specifically, the level corresponding to the safety / comfort function which is the function type of the ECU 400e) among the levels corresponding to the function type of each ECU to be updated of the shared key 60a. (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 level 1042 is set to 4 corresponding to the ECU 400e having a 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 level 1042 is set to 3 corresponding to the ECU 400a having a drive system function and the ECU 400b having a 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 level 1042 is set to 2 corresponding to the ECUs 400c and 400d having the body system 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 level 1042 is set to 1 corresponding to the ECU 400f having an infotainment system 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 level 1042 corresponding to this message ID is set to the highest level of 4, with special treatment of 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 level 1042 corresponding to this message ID is set to 4 corresponding to the ECU 400e having a safety / 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 level 1042 corresponding to this message ID is set to 3 corresponding to the ECU 400b having the chassis system function.

The message ID "0x203" is a message ID for an update message for updating the firmware of the ECU 400a. The value of level 1042 corresponding to this message ID is set to 3 corresponding to the ECU 400a having a 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 level 1042 corresponding to this message ID is set to 2 corresponding to the ECU 400c having a body system function.

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

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

[1.9 Configuration of ECU 400a]
FIG. 9 is a configuration diagram of the ECU 400a. The ECU 400a includes a key holding unit 402, a frame transmitting / receiving unit 460, a frame interpreting unit 450, a receiving ID determination unit 430, a receiving ID list holding unit 440, a frame processing unit 410, a frame generating unit 420, and data acquisition. It is configured to include part 470. Each of these components is a functional component, and each function is realized by a communication circuit in the ECU 400a, a processor that executes a control program stored in a memory, a digital circuit, or the like. The ECUs 400b to 400f also 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. The key holding unit 402 may hold the MAC key used when adding the MAC as the encryption process to the data in the data frame according to the CAN protocol. Further, the key holding unit 402 may hold the session key used for the encryption processing related to the communication with other ECUs and the like. The session key can also be used to generate the MAC.

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

The frame interpretation unit 450 receives the frame value from the frame transmission / reception unit 460 and interprets it so as to map it to each field in the CAN protocol. The value determined to be the ID field is transferred to the reception ID determination unit 430. Depending on the judgment result notified from the reception ID judgment 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 judgment result is received. After that, it is decided whether to stop receiving the frame (that is, stop interpreting it as the frame). If it is determined that the frame does not conform to the CAN protocol, the frame generation unit 420 is notified to transmit an error frame. Further, when the frame interpreting unit 450 receives an error frame, that is, when it interprets that the value in the received frame is an error frame, the frame interpreting unit 450 discards the frame after that, that is, stops interpreting the frame. To 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 list of message IDs held by the reception ID list holding unit 440. Determine whether or not to do so. 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 processing related to a function different for each ECU according to the received frame data. For example, the ECU 400a connected to the engine 310 may perform predetermined control according to the relationship between the rotation speed of the engine 310 and the state of a part of the vehicle indicated by the frame data received from another ECU.

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

The frame generation unit 420 configures 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 the error frame. Further, the frame generation unit 420 constructs a data frame by adding a predetermined message ID to the value of the data field determined based on the data notified by the data acquisition unit 470, and notifies the frame transmission / reception unit 460. To send. The frame generation unit 420 may add a MAC generated by using the MAC key or the session key to the value of the data field.

[1.10 Received ID List]
FIG. 10 shows an example of the reception ID list 900 held by the reception ID list holding unit 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 paid attention to.

The reception ID list held by the reception ID list holding unit 140 of the master ECU 100 also has a configuration in which the message IDs of the messages that can be received by the master ECU 100 are listed in the same manner as the reception ID list 900.

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

11 and 12 are diagrams showing 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 external tool 30a as one of the external tools 30 and the ECU 400a which is one of the ECUs 400a to 400f will be described. Further, a scene in which 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 will be described. Specifically, an update message with a message ID "0x102" for updating the shared key 60d held by each of the ECU 400a having a drive system function and the ECU 400b having a chassis system function is sent from the external tool 30a to the in-vehicle network system. It will be transmitted to 10. Since the operation of the ECU 400b is the same as the operation of the ECU 400a, the description thereof will be omitted here.

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

The transmission / reception unit 101 of the master ECU 100 receives the public key certificate 40a, and the determination unit 103 verifies the public key certificate 40a (step S1002). Regarding the verification of the public key certificate 40a, for example, the signature by the certificate authority is verified, and the private key corresponding to the public key described in the public key certificate 40a by the challenge response (CR) authentication method is used by the external tool 30a. Check if it holds. In the CR authentication method, for example, when the master ECU 100 transmits a random number to the external tool 30a and the external tool 30a returns an encrypted random number which is the result of encrypting the random number with the private key to the master ECU 100, the master ECU is released. The encrypted random number is decrypted with the public key in the key certificate 40a, and it is confirmed whether it is equal to the first transmitted random number. If the verification in step S1002 fails, the master ECU 100 performs error processing (step S1003). Due to the error processing in step S1003, the 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 effect of an error to the external tool 30a as error processing.

If the verification in step S1002 is successful, the master ECU 100 generates a session key used for performing encryption processing in communication with the external tool 30a using random numbers (step S1004). For example, when encrypting the data in the 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. It is used as a key to do so.

Following 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 obtains the encrypted session key which is the result of the encryption and the public key certificate 40c of the master ECU 100. It 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 decrypts the encrypted session key transmitted and received from the master ECU 100 in step S1004 with the private key held by the external tool 30a to acquire the session key (step). S1008).

Following step S1008, the external tool 30a generates an update message for updating the shared key 60d with the message ID "0x102", and performs encryption processing on the update message using the session key (step S1009). ). As an example of encryption processing for the update message, in the data field, for example, the data required for updating the shared key 60d (for example, the key data when the ECU 400a is to be updated by a keyed hash function or the like). And encrypt the data or add a MAC to the data. Further, even when data is not required for updating the shared key 60d, it is possible to store, for example, the MAC corresponding to all or part of the update message 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 kind of processing is performed as the encryption process corresponding to the update message. Then, each ECU updates in response to the update message in which the predetermined encryption process (for example, addition of MAC) is appropriately performed (that is, the verification using the session key is successful) according to the regulation, and the predetermined encryption is performed. If the processing is not performed properly, the update is suppressed for the update message.

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

The reception ID determination unit 130 determines whether or not the message ID of the message (frame) received by the transmission / reception unit 101 of the master ECU 100 is the ID to be received by the transmission by the external tool 30a in step S1010. (Step S1011). It is determined that the message IDs "0x100" to "0x104" for updating the shared key and the message IDs "0x200" to "0x206" for updating the firmware are IDs to be received. Here, since the explanation is based on the assumption that the external tool 30a sends an update message, the message (frame) from the external tool 30a is called an update message, but it may not actually be an update message. , Therefore, the 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 the message ID for a message other than the update message as an ID to be received from the external tool 30 (for example, the external tool 30a, etc.) connected to the diagnostic port 600. ..

If it is determined in step S1011 that the message ID of the message received by the transmission / reception unit 101 is not an ID to be received, the determination unit 103 of the master ECU 100 stops the processing related to the message of that message ID, and the transmission / reception unit In 101, the process ends without receiving the contents (data field, etc.) after the ID field (step S1012).

When the message ID of the message received by the transmission / reception unit 101 is determined to be the ID to be received in step S1011, the determination unit 103 of the master ECU 100 determines the message ID "0x102" of the received message and the external tool 30a. The level of the update authority information described in the public key certificate 40a of the above is received depending on whether or not it 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 or not the message is an permitted 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 an permitted update message, error processing is performed (step S1014). Due to 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 relationship with the update message of the message ID “0x102” is the correspondence relationship indicated by the level information 1040 (FIG. 8). Since it matches (see), the determination unit 103 determines that the update message received from the external tool 30a is an permitted update message.

In step S1013, when it is determined that the transmission of the received message is within the authority range of the external tool 30a (that is, when it is determined that the received message is an permitted update message), the determination unit 103 determines the frame. Instruct the generation unit 120 to generate an update message for transfer (step S1015). As a result, in the frame generation unit 120, a new update message (frame) is used for transfer to the bus 500b (that is, for transfer to another ECU) based on the original update message received by the master ECU 100 from the external tool 30a. To generate. For example, when the master ECU 100 has a different session key used for communication with the external tool 30a and a session key used for communication with another ECU (at least each ECU connected to the bus 500b), a frame is generated. If the encryption process applied to the original update message is encrypted, the unit 120 performs decryption using the session key for communication with the external tool 30a, and uses the result of the process for communication with another ECU. A new update message is generated by encrypting using the session key. If the encryption process applied to the original update message is the addition of a MAC, the frame generator 120 generates a MAC using the session key used for communication with other ECUs, and the MAC of the original update message. Is replaced with the generated MAC to generate a new update message. In this case, if the MAC of the original update message is verified and the verification fails, error processing may be performed. Further, for example, when the session key used by the master ECU 100 for communication with the external tool 30a and the session key used for communication with another ECU are the same, the frame generation unit 120 is used with the original update message. Generate the same new update message.

Following step S1015, the frame transmission / reception unit 160 sends an 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 the external tool 30a, the master ECU 100 has succeeded in verifying the update authority information (that is, the verification of the public key certificate), and the update message is transmitted by the external tool 30a. When the update authority information indicates that it is within the authority range, the update message is forwarded to the bus 500b. When the verification of the update authority information fails, or when the update authority information does not indicate that the update message is within the authority range of the external tool 30a, the update message is transferred to the bus 500b. I can't.

The update message sent to the bus 500b by the master ECU 100 is transferred to the bus 500a and the bus 500c by the gateway 300. As a result, 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 that message ID. The update corresponding to the update message can be executed by the ECU.

In the ECU 400a (see FIG. 9), the frame transmission / reception unit 460 receives the update message, the frame interpretation unit 450 interprets the content of the message, and inquires the reception ID determination unit 430 whether or not the ID to be received is. The reception ID determination unit 430 refers to the reception ID list held by the reception ID list holding unit 440, and determines whether the value of the ID field of the received message is the ID to be received (step S1017). When 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 relates to the received message. The process is stopped, and the frame transmission / reception unit 460 ends the process without receiving the contents after the ID field (step S1018).

When 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 determines the message by the frame processing unit 410. The process corresponding to (that is, the update message) (that is, the update of the shared key 60d) is executed (step S1019). In the frame processing unit 410, from the shared key 60d currently held by the key holding unit 402, a new shared key 60d to be updated is obtained by a keyed hash function using the key data in the data field of the update message. Generate. It is not always necessary to use a keyed hash function for updating, and another example is to use a keyless hash function (one-way function) to update the original shared key to a new shared key. Be done. In the ECU 400a, the process (decryption or MAC verification) corresponding to the encryption process (encryption or MAC addition) applied to the update message is performed using the session key to acquire the key data of the update message.

After updating the shared key 60d, the ECU 400a sends a message (referred to as an update result message) indicating the update result to the bus 500a so as to be transmitted to the master ECU 100 (S1020). 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 the 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). If an error occurs during the update (for example, if 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, the master ECU 100 updates the shared key 60d (see FIG. 6) held by the key holding unit 102 in the same manner as the ECU 400a (step S1021). The key holding unit 102 holds the master ECU 100 only when it receives both an update result message indicating that the update is successful from the ECU 400a and an update result message indicating that the update is successful from the ECU 400b, for example. The shared key 60d may be updated.

The master ECU 100 transmits the update result message received in step S1020 to the external tool 30a via the diagnostic port 600 by sending it to the bus 500d (step S1022). As a result, the external tool 30a receives the update result message, knows that the target update has been completed in the in-vehicle network system 10, and notifies the user, for example, that the update has been completed (for example, the external tool 30a has a display device). If so, it can be displayed).

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, 400b and the master ECU 100 has been shown, but the update message for updating the shared key held by the other ECUs has been shown. Is transmitted, or when an update message for updating the firmware in the ECU is transmitted, each device performs the same operation. The external tool 30a may sequentially transmit each update message after transmitting the authentication request once. In this case, after the processes from step S1001 to step S1008 are executed once, the processes after step S1009 are repeated every 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 in the ECU that is the target of the update message, the content of the updated firmware is specified. Rewrite the firmware based on the information in. The firmware may include, for example, software such as a program in the ECU, data used in the program, and may include, for example, microcode in the 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. Further, in the description here, for convenience, the shared key and the firmware are treated separately, but the firmware may be treated as including the shared key.

[1.12 Effect of Embodiment 1]
In the vehicle-mounted network system 10 according to the first embodiment, whether or not the external tool 30 connected to the diagnostic port 600 has the authority to send an update message for updating the data in the specific ECU, that is, the external tool 30 is specific. Whether or not the user has the authority to update the data in the ECU is determined based on the level determined according to the function type of the ECU indicated by the update authority information indicating the authority authorized for the external tool 30. doing. This makes it possible to prevent an unauthorized external tool from updating the shared key or firmware in the ECU. Also. For each external tool, for example, the level of update authority information can be set (and certified) at different levels according to the confidentiality and reliability of the external tool, the reliability of the business operator handling the external tool, and various other circumstances. It is also possible to distribute external tools with different levels to different maintenance companies, etc., and it is possible to flexibly limit the update authority according to various circumstances. For example, an external tool with sufficient security such as confidentiality and reliability can certify a higher level of authority. The ability to set the level of update authority information for each external tool in this way is for the purpose of efficiently and flexibly designing and manufacturing external tools according to the application, or for ensuring the operational security of external tools. It is useful because it can be done flexibly according to the situation.

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

In the vehicle-mounted 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 the update message from the external tool 30 is the update authority information. Only when it is within the range of the indicated authority (level), the external tool 30 is permitted to update the data in the ECU with the update message.

In the in-vehicle network system 10a according to the present embodiment, 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 are determined in determining whether to allow the update message of the external tool 30. Refer to the status of the remaining amount of. The configuration of the vehicle-mounted network system 10a according to the present embodiment is substantially the same as that of the vehicle-mounted network system 10 (see FIG. 1) shown in the first embodiment. Hereinafter, the same reference numerals are used for the same vehicles as those of the first embodiment. ..

[2.1 Overall configuration of in-vehicle network system 10a]
FIG. 13 is a diagram showing an overall configuration of the vehicle-mounted network system 10a according to the second embodiment. In addition to the in-vehicle network system 10a, the external tool 30 is shown in the figure.

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

The ECU 400g is connected to the bus 500b, controls the charging and discharging of the battery (storage battery) 800, acquires and manages the remaining amount of the storage battery 800, and periodically forms a frame indicating the state of the remaining battery amount in a network (that is,). It is transmitted 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 showing an example of the level information 2040 held by the level information holding unit 104 of the master ECU 100 in the second embodiment.

The level information 2040 is information in which the message ID 2014, the level 2042, the battery level condition 2043, and the vehicle state condition 2044 are associated with each other, and the determination unit 103 determines whether or not to allow the 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. Battery level condition 2043 indicates the battery level condition required to allow the update message, for example, the battery level is set to a sufficient amount for updating, and as a specific example, it is set. With the fully charged charge amount as 100%, either the remaining amount of 50% or more of charging or the remaining amount of 80% or more of charging is set. Further, the vehicle state condition 2044 indicates a vehicle state condition required for permitting the update message, for example, a stopped state (a state in which the vehicle speed is zero) and an engine OFF state (the engine 310 is stopped). One of the above states) is set.

For example, in the update message for updating the shared key of the message ID "0x104", the update authority information level is 1 or higher, the remaining battery level of the storage battery 800 is 50% or more charged, and the vehicle state is stopped. Indicates that it is allowed when. Further, the update message for updating the firmware of the message ID "0x201" is when the update authority information level is 4, the remaining battery level of the storage battery 800 is 80% or more, and the vehicle state is the engine OFF state. Indicates that it is allowed.

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

15 and 16 are diagrams showing 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 external tool 30a as one of the external tools 30 and the ECU 400a which is one of the ECUs 400a to 400g will be described. Further, a scene in which 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 will be described. Specifically, an update message with a message ID "0x102" for updating the shared key 60d held by each of the ECU 400a having a drive system function and the ECU 400b having a chassis system function is sent from the external tool 30a to the in-vehicle network system. It will be transmitted to 10. Since the operation of the ECU 400b is the same as the operation of the ECU 400a, the description thereof will be omitted here. Further, since the processes of steps S2001 to S2012 and steps S2014 to S2022 are equivalent to the processes of steps S1001 to S1012 and steps S1014 to S1022 shown in the first embodiment (see FIGS. 11 and 12). Although the description is omitted, only steps S2013a to S2013c different from the first embodiment will be described here.

In step S2013a, the determination unit 103 of the master ECU 100 holds 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 holding unit 104. It is determined whether or not the received message satisfies the condition regarding the authority level as an appropriate update message depending on whether or not it matches the correspondence between the message ID 2041 and the level 2042 in the level information 2040. That is, the determination unit 103 determines based on the level information 2040 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 does not satisfy the condition regarding 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 relationship with the update message of the message ID “0x102” is the correspondence relationship indicated by the level information 2040 (FIG. 14). Since it matches (see), 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 process to the next step S2013b.

In step S2013b, the determination unit 103 checks whether or not the remaining battery level of the storage battery 800 satisfies the condition. When the ECU 400g that manages the remaining battery level of the storage battery 800 periodically transmits a message (referred to as a remaining battery level frame) indicating the remaining battery level, the master ECU 100 uses the remaining battery level frame from the ECU 400g. Received by the frame transmitter / receiver 160. It is assumed that the reception ID list held by the reception ID list holding unit 140 of the master ECU 100 includes the message ID of the battery remaining frame from the ECU 400g. The determination unit 103 checks whether or not the battery level indicated by the battery level frame received from the ECU 400g satisfies the 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 is moved 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). It is also possible that the ECU 400g does not periodically transmit the battery remaining amount frame indicating the battery remaining amount state. 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, the present) may be acquired.

In step S2013c, the determination unit 103 checks whether the vehicle condition satisfies the condition. When the ECU 400a related to the engine 310 periodically transmits a message (referred to as a vehicle state frame) indicating vehicle state information such as the engine state and vehicle speed, the master ECU 100 transmits the vehicle state frame from the ECU 400a to the frame transmission / reception unit. Receive at 160. It is assumed that the reception ID list held by the reception ID list holding unit 140 of the master ECU 100 includes the message ID of the vehicle state frame from the ECU 400a. The determination unit 103 checks whether or not 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. To do. If the vehicle condition is satisfied, the determination unit 103 determines that the update message received from the external tool 30a is permitted, and shifts the process to step S2015. If the vehicle condition is not satisfied (that is, the check result is NG), error processing is performed (step S2014). It is also possible that the ECU 400a does not periodically transmit the vehicle state frame. In this case, in step S2013c, the master ECU 100 transmits a frame requesting the ECU 400a to transmit the vehicle state frame, so that the ECU 400a sends the frame. The vehicle state frame may be received to acquire the vehicle state at the time when the update message is received (that is, the present).

[2.4 Effect of Embodiment 2]
In the in-vehicle network system 10a according to the second embodiment, not only the authority level but also the remaining battery level and the vehicle state determine whether or not the processing (update) related to the update message from the external tool 30 is permitted. In this case, the judgment is made according to whether the update message has been sent. Therefore, in addition to the effect of the in-vehicle network system 10 according to the first embodiment, it has the following effects. That is, by checking the remaining battery level, the update process of the data (shared key or firmware) in the ECU can be reliably completed without interruption in the middle. In addition, by checking the vehicle status, it is possible to avoid transferring the update message and performing the update when the load on the ECU is high and the bus traffic increases, for example, while the vehicle is running, and there is a possibility that the update will succeed. Can be 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 that the notification regarding the expiration date of the shared key can be performed.

[3.1 Configuration of master ECU (update management device) 100a]
FIG. 17 is a configuration diagram of the master ECU 100a. The master ECU 100a has a configuration in which a time information acquisition unit 180 and a key update confirmation unit 190 are added to check the expiration date of the shared key in addition to the components of the master ECU 100 shown in the first embodiment. Each of these components is a functional component, and each function is realized by a communication circuit in the 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 shown in the first embodiment will be omitted.

The time information acquisition unit 180 is composed of a time measuring 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 a predetermined expiration date for the shared key held by the key holding unit 102, and is set in advance as an alert notification timing. A key update alert message is generated by the frame generation unit 120 and transmitted from the frame transmission / reception unit 160 at a time when the timing has passed (that is, before a certain period of the expiration date).

FIG. 18 shows 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 of 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 the security of the shared key pointed to by the corresponding shared key identification information. The alert notification timing 3312 indicates a timing at which the 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, if the shared key 60a is used, a key update alert message is sent from 3 months before the expiration date, and if the shared key 60d is used, a key update alert message is sent from 1 month before the expiration date.

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

[3.2 Key update alert message]
FIG. 19 is a diagram showing 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 maintenance company. Includes URL (Uniform Resource Locator). Further, the screen 3320 includes a GUI (Graphical User Interface) button 3321 for transitioning to a screen for setting the destination to the dealer's address by the navigation system. The dealer's information may be registered in the master ECU 100a in advance at the time of sale, for example, or may be acquired via an ECU having a telematics function.

For example, if the driver who sees 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 will 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 vehicle-mounted network system.

[Effect of 3.3 Embodiment 3]
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, the head unit provides warning information (screen) that prompts the driver of the vehicle to update the key. Display on the display device. As a result, a warning for ensuring the security of 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 as to attach the vehicle identification information to the update result message and transmit it to the external tool 30, and the external tool 30 becomes the server 35. An example of communicating is described.

[4.1 Server]
The server 35 that communicates with the external tool 30 is a computer located outside the vehicle on which the in-vehicle network system 10 is mounted. Assuming that the in-vehicle network system 10 is mounted on each of the plurality of vehicles, the server 35 uses the external tool 30 for which vehicle (that is, the in-vehicle network system) and what kind of update (data in the ECU). Manage if you have done (update).

[4.2 Shared key update sequence]
Hereinafter, as an example of the update management method in the present embodiment, the 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. The operation (shared key update sequence) when updating the shared key held by the ECU will be described with reference to FIGS. 20 and 21.

20 and 21 are diagrams showing 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. Since the processes from step S3001 to step S3021 are the same as the processes from step S1001 to step S1021 shown in the first embodiment (see FIGS. 11 and 12), the description thereof will be omitted. Here, the process 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, for example, a login request using a pre-registered ID (for example, a tool ID) and a password to the server 35.

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

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

In step S3022, the master ECU 100 sends an update result message with vehicle identification information, which is a message including vehicle identification information, to the bus 500d in addition to the update result from the ECU 400a, so that the external tool 30a is transmitted via the 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 may 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, a public key certificate 40c of the master ECU 100 (see FIG. 3) or the like. is there.

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

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

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

[4.4 Effect of Embodiment 4]
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. In addition, when an unauthorized external tool is found, log information 4000 can be used to identify the range of influence by the external tool.

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

(1) The shared key shown in the above embodiment shows an example in which the shared range is distinguished by the function type for classifying the functions, but the sharing range is not limited to this, and the master ECU and one or more others are used. The unit in which the ECU and the ECU share the shared key can be arbitrarily determined in the in-vehicle 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 that case, the level information may be set by distinguishing the domain as the level of authority required for updating. Further, in the above embodiment, an example is shown in which the external tool 30 has a public key certificate including update authority information in which the authority level is set based on the function type, but the update corresponding to the automobile manufacturer and the vehicle model is shown. You may have a public key certificate that includes the update authority information for which the authority of 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 include the new shared key itself in the update message and send it. In this case, if the value of the shared key does not fit within one frame of CAN, it may be divided into a plurality of frames and transmitted.

(3) In the above embodiment, an example of transmitting an update message for updating the data (shared key, firmware, etc.) in the ECU from the external tool 30 is shown, but in addition to this, a message for failure diagnosis or the like is transmitted. Can be sent. For messages other than the update message, the in-vehicle network system (for example, the master ECU) may perform processing corresponding to the message without determining the authority based on the level information. Further, for any message including a message for failure diagnosis, etc., the authority information indicating the level of authority indicates whether the transmission of the message in the in-vehicle network system (for example, the master ECU) is within the authority range permitted by the external tool 30. It 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 levels, and may be set higher or lower.

(5) The method of classifying the functional types shown in the above embodiment is only an example, and may be subdivided in more detail, for example. The function types may be classified most finely, and for example, the level of authority related to updating data in the ECU may be set for each ECU.

(6) In the second embodiment, an example of distinguishing by the ratio (percentage) of the storage battery 800 to the full charge is shown as the battery remaining condition condition 2043, but it 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 source located outside the vehicle may be set. As a result, for example, it is possible to allow a certain shared key and firmware update only during charging.

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

(8) In the third embodiment, an example is shown in which the time information acquisition unit 180 of the master ECU 100a acquires the current time by the timing mechanism in order to confirm the expiration date of the shared key. The time information indicating the current time may be acquired from the carrier network of the telephone, or the time information may be acquired from the GPS (Global Positioning System) signal. Also, the master ECU 1
00a may acquire time information from another ECU.

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

(10) In the above embodiment, authentication is performed between the external tool 30 and the master ECU, but an electronic circuit (for example, a memory, a processor, etc.) responsible for authentication is connected to the diagnostic port 600, which is an OBD2 compliant connector or the like. ) Etc. 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 is 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 is completed by the diagnostic port 600, the authentication may be performed between the external tool 30 and the master ECU as shown in the above embodiment. The diagnostic port 600 may be realized by another connector instead of the OBD2 compliant connector or the like. Further, the diagnostic port 600 may be realized by including the wireless communication circuit so that it can be connected to the external tool 30 by wireless communication.

(11) In the second embodiment, an example in which the master ECU 100 checks the remaining battery level and the vehicle state when the update message is received is shown, but only one of the remaining battery level and the vehicle state is checked. It's fine as a matter of fact. Further, the update authority information may not only indicate the level of authority, but also indicate the conditions for update authority such as the battery level condition and the vehicle condition condition shown in the second embodiment. For example, the update authority information specifies a stopped state, which is the state of the vehicle, or a state in which the engine is stopped as a vehicle state condition, and sends an update message when the vehicle is in the specified state. As one condition, it may be expressed that the external tool has the authority to cause the ECU to perform the update. Further, for example, the update authority information specifies the state of the remaining amount of the battery that supplies power to the ECU as the battery remaining amount condition, and sends an update message when the battery is in the state of having the specified remaining battery amount. It may indicate that the external tool has the authority to cause the ECU to perform the update on the condition that the transmission is performed. Then, for example, the master ECU 100 checks (steps S2013b, S2013c) based on the battery remaining amount condition and the vehicle state condition indicated by the update authority information instead of the battery remaining amount condition 2043 and the vehicle state condition 2044 in the level information 2040. You may do it. As a result, the authority with certain conditions is recognized for the external tool according to the reliability of the external tool, and the public key certificate that describes the update authority information indicating the condition and the level of authority is issued. It becomes possible to operate as if issuing.

(12) In the above embodiment, the data frame in the CAN protocol is described in the standard ID format, but the extended ID format may be used. 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 embodiment, an example is shown in which another ECU is not connected to the bus 500d connecting the diagnostic port 600 to which the external tool 30 is connected and the master ECU, but the ECU may be connected. .. However, the ECU connected to the bus 500d other than the master ECU transmits the data (shared key, firmware, etc.) by the external tool 30 (for example, the external tool 30 that succeeds in authentication by the master ECU and obtains the session key). Can be updated with an update message. Therefore, 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 sends an update message instructing the ECU to update beyond the recognized authority level, the master ECU sends the update message to the permitted update message. (Step S1013), if it is not an permitted 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 suppress the update based on the update authority information of the external tool 30. That is, in any ECU 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 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 more ECUs may be suppressed. As shown in the embodiment, the method of switching whether or not the master ECU collectively transfers the update message is useful in terms of efficiency. Further, the function type of the ECU connected to the transfer destination bus by the gateway 300 or the message ID that can be received by the ECU is managed, and when the gateway 300 receives the update message, the gateway 300 is connected to the transfer destination bus. Unnecessary update messages may not be transferred based on the function type of the ECU or the message ID that can be received by the ECU.

(15) The functional configurations of the master ECUs 100, 100a, ECU 400a, etc. shown in the above embodiment are merely examples, and functional divisions different from the above-mentioned functional configurations may be performed. For example, the master ECUs 100 and 100a are a receiving unit corresponding to the receiving function of the transmitting / receiving unit 101, and a verification unit and a determination unit 103 in charge of verifying a public key certificate (public key certificate including update authority information) in the determination unit 103. A part of the frame generation unit 120, a part of the frame transmission / reception unit 160, and a transfer unit that controls the transmission of the update message may be included. In this case, for example, the receiving unit receives update authority information indicating the 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. Responsible for receiving update messages instructing to update the data held by. In addition, the verification unit has a function of verifying the update authority information received by the receiving unit. Further, when the update authority information indicates that the verification by the verification unit is successful and the transmission of the update message is within the authority range of the external tool 30 when the update message is received by the receiving unit. , A function to transfer the update message to the bus 500b and suppress the transfer when the verification by the verification unit fails or when the update authority information does not indicate that the update message is within the authority range of the external tool 30. To bear. Further, the control program executed by the processor in the master ECUs 100 and 100a having the processor may be a program for causing the master ECUs 100 and 100a to execute, for example, the next predetermined update management process. The predetermined update management process includes an update authority information receiving step for receiving update authority information indicating the authority of the external tool sent from the external tool connected to the diagnostic port via the diagnostic port, and an update authority information receiving step. In the verification step for verifying the update permission information received in, the update message reception step for receiving the update message sent from the external tool via the diagnostic port, and the update message reception step for receiving the update message. 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 the bus for communication with the ECU. When the verification in the verification step fails, or when the update permission information does not indicate that the transmission of the update message is within the permission range of the external tool, the transfer control step for suppressing the transfer is included.

(16) The master ECU and other ECUs in the above embodiment are, for example, devices including digital circuits such as processors and memories, analog circuits, communication circuits, etc., but hard disk devices, displays, keyboards, mice, etc. Other hardware components such as may be included. Further, 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 composed of one system LSI (Large Scale Integration). The system LSI is an ultra-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. .. A computer program is recorded in the RAM. When the microprocessor operates according to the computer program, the system LSI achieves its function. Further, each part of the component component constituting each of the above devices may be individually integrated into one chip, or may be integrated into one chip so as to include a part or all of the components. Further, although the system LSI is used here, it may be referred to as an IC, an LSI, a super LSI, or an ultra LSI depending on the degree of integration. Further, the method of making an integrated circuit is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor. An FPGA that can be programmed after the LSI is manufactured, or a reconfigurable processor that can reconfigure the connection and settings of the circuit cells inside the LSI may be used. Furthermore, if an integrated circuit technology that replaces an LSI appears due to advances in semiconductor technology or another technology derived from it, it is naturally possible to integrate functional blocks using that technology. The application of biotechnology, etc. is possible.

(18) A part or all of the components constituting each of the above devices may be composed of an IC card or a single module that can be attached to and detached from each device. The IC card or the module is a computer system composed of 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 a 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 shared key update sequence shown above. Further, it may be a computer program that realizes these methods by a computer, or it may be a digital signal composed of the computer program. Further, as one aspect of the present invention, the computer program or a recording medium capable of reading the digital signal by a computer, for example, a flexible disk, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, or a BD. (Blu-ray (registered trademark) Disc), may be recorded on a semiconductor memory or the like. Further, it may be the digital signal recorded on these recording media. Further, as one aspect of the present invention, the computer program or the digital signal may be transmitted via a telecommunication line, a wireless or wired communication line, a network typified by the Internet, data broadcasting, or the like. Further, one aspect of the present invention is a computer system including a microprocessor and a memory, in which the memory records the computer program, and the microprocessor may operate according to the computer program. .. Further, it is carried out by another independent computer system by recording and transferring the program or the digital signal on the recording medium, or by transferring the program or the digital signal via the network or the like. You may do so.

(20) The scope of the present invention also includes a form realized by arbitrarily combining the above-described embodiment and each component and function shown in the above-described modification.

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

10,10a In-vehicle network system 20 Key issuing organization 21 Manufacturer 30, 30a, 30b External tool 35 Server 101 Transmission / reception unit 102,402 Key holding unit 103 Judgment unit 104 Level information holding unit 110,410 Frame processing unit 120,420 Frame generation unit 130,430 Reception ID judgment unit 140,440 Reception ID list holding unit 150,450 Frame interpretation unit 160,460 Frame transmission / reception unit 180 Time information acquisition unit 190 Key update confirmation unit 200 Head unit 300 Gateway 310 Engine 320 Brake 330 Door open / close sensor 340 Window open / close sensor 350 Airbag 470 Data acquisition unit 500a-500d Bus 600 Diagnostic port 800 Storage battery

Claims (9)

It is an update management method executed by the update management device in the in-vehicle network system.
The in-vehicle network system includes a plurality of electronic control units that communicate via a network.
The update management device is
It is one of the plurality of electronic control units, and is an electronic control unit.
Can communicate with external devices
The update management method is
Verification using the certificate of the external device is performed.
When the verification of the certificate is successful and an update message instructing the update of the firmware of the plurality of electronic control units other than the update management device is received from the external device, the update message by the external device is received. Is determined whether or not the transmission of the external device is within the authority range of the external device.
(I) When it is determined that the transmission of the update message by the external device is within the authority range of the external device, the update message is transferred to the network.
(Ii) When it is determined that the transmission of the update message by the external device is not within the authority range of the external device, the transfer is suppressed.
Update management method. The plurality of electronic control units communicate according to the Controller Area Network (CAN) protocol and communicate with each other.
The update management method according to claim 1, wherein the external device transmits the update message according to the CAN protocol. Whether or not the transmission of the update message from the external device is within the authority range of the external device is determined based on the message ID of the update message, and the transmission of the update message is the transmission of the external device of the external device. The update management method according to claim 2, wherein when it is determined that the user is within the authority range, the update is executed for the electronic control unit defined to receive the update message having the message ID. The update management method according to claim 1, wherein 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 is suppressed. The update management method according to claim 1, wherein when the battery that supplies power to each electronic control unit in the in-vehicle network system does not have a predetermined battery level, the transfer of the update message to the network is suppressed. The update according to claim 1, wherein (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 are transmitted to the external device. Management method. The alert message is sent to the electronic control unit that controls the display.
The update management method according to claim 1. An update management device for in-vehicle network systems
The in-vehicle network system includes a plurality of electronic control units that communicate via a network.
The update management device is
It is one of the plurality of electronic control units, and is an electronic control unit.
Can communicate with external devices
A receiving unit that receives a certificate of the external device and an update message instructing to update the firmware from the external device.
A verification unit that verifies the certificate 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 it indicates that the transmission of the update message is within the authority range of the external device, the update message is displayed. A transfer unit that transfers to the network and (ii) suppresses the transfer when the transmission of the update message is not within the authority range of the external device.
Update management device equipped with. 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.
The update management device is
The electronic control unit, which is one of the plurality of electronic control units.
Can communicate with external devices
The control program
Verification using the certificate of the external device is performed.
If the verification of the certificate is successful and the update message instructing the firmware update is received from the external device, is the transmission of the update message by the external device within the authority range of the external device? Make a judgment as to whether or not
(I) When it is determined that the transmission of the update message by the external device is within the authority range of the external device, the update message is transferred to the network.
(Ii) When it is determined that the transmission of the update message by the external device is not within the authority range of the external device, the transfer is suppressed.
Control program.

Images