WO2016075865A1 - 更新管理方法、更新管理装置及び制御プログラム - Google Patents

更新管理方法、更新管理装置及び制御プログラム Download PDF

Info

Publication number
WO2016075865A1
WO2016075865A1 PCT/JP2015/005165 JP2015005165W WO2016075865A1 WO 2016075865 A1 WO2016075865 A1 WO 2016075865A1 JP 2015005165 W JP2015005165 W JP 2015005165W WO 2016075865 A1 WO2016075865 A1 WO 2016075865A1
Authority
WO
WIPO (PCT)
Prior art keywords
update
message
external tool
update message
ecu
Prior art date
Application number
PCT/JP2015/005165
Other languages
English (en)
French (fr)
Inventor
芳賀　智之
松島　秀樹
前田　学
勇二 海上
安齋　潤
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to JP2016558862A priority Critical patent/JP6618480B2/ja
Priority to CN201910654690.5A priority patent/CN110377310B/zh
Priority to EP15858625.5A priority patent/EP3219553B1/en
Priority to EP18186944.7A priority patent/EP3412514B1/en
Priority to CN201580027431.XA priority patent/CN106458112B/zh
Publication of WO2016075865A1 publication Critical patent/WO2016075865A1/ja
Priority to US15/416,061 priority patent/US10637657B2/en
Priority to US16/820,428 priority patent/US11283601B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
    • B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
    • B60R16/023—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements for transmission of signals between vehicle parts or subsystems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/068—Network architectures or network communication protocols for network security for supporting key management in a packet data network using time-dependent keys, e.g. periodically changing keys
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2107—File encryption
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2113—Multi-level security, e.g. mandatory access control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2137—Time limited access, e.g. to a computer or data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2151—Time stamp
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • 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.
  • ECUs electronice control units
  • a network connecting these ECUs is called an in-vehicle network.
  • CAN Controller Area Network
  • ISO11898-1 a standard for in-vehicle networks.
  • the communication path is composed of two buses, and an ECU connected to the bus is called a node.
  • Each node connected to the bus transmits and receives a message called a frame.
  • the transmission node transmits an ID (called a message ID) for each frame (that is, sends a signal to the bus), and each reception node is predetermined.
  • the in-vehicle network has a port (hereinafter referred to as “diagnostic port”) that is an interface that communicates with an external tool (for example, an external device such as a failure diagnostic tool) called OBD2 (On-Board Diagnostics 2). Used for ECU diagnosis.
  • diagnostic port an interface that communicates with an external tool (for example, an external device such as a failure diagnostic tool) called OBD2 (On-Board Diagnostics 2). Used for ECU diagnosis.
  • OBD2 On-Board Diagnostics 2
  • Patent Document 1 has a risk that the firmware of all ECUs may be illegally rewritten when an identification code assigned to an external tool for updating firmware is leaked.
  • the present invention reduces the risk of unauthorized rewriting of firmware of all ECUs when confidential information assigned to an external tool is leaked, and updates management for causing external tools 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 the update management device.
  • an update management method 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.
  • update authority information indicating authority of the external tool
  • an update message instructing update of data held by one or a plurality of the electronic control units is transmitted from the external tool
  • 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 corresponding to the update message When the update is executed by the unit and the verification fails, or the transmission of the update message is the authority range of the external tool.
  • the update permission information does not indicate that a inner is updated management method for inhibiting the update corresponding to the update message by said one or more electronic control units.
  • an update management device is an electronic control unit connected to a diagnosis port in an in-vehicle network system including a plurality of electronic control units that communicate via a bus.
  • An update management apparatus update authority information indicating the authority of the external tool transmitted from the external tool connected to the diagnostic port, and one or more electronic control units
  • a receiving unit that receives an update message that instructs to update the data held by the receiving unit, a verification unit that verifies the update authority information received by the receiving unit, and the update message received by the receiving unit. The verification by the verification unit is successful and the transmission of the update message is within the authority of the external tool.
  • the update authority information indicates that the update message is transferred to the bus, and when the verification by the verification unit fails, or the transmission of the update message is within the authority range of the external tool.
  • the update management apparatus includes a transfer unit that suppresses the transfer.
  • a control program is provided as an electronic control unit connected to a diagnosis 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 apparatus having a processor to execute predetermined update management processing, wherein the update management processing is transmitted from an external tool connected to the diagnostic port via the diagnostic port.
  • An update authority information receiving step for receiving update authority information indicating the authority of the external tool, a verification step for verifying the update authority information received in the update authority information receiving step, and the diagnostic port from the external tool.
  • the update message is transferred to the bus, and when the verification in the verification step fails, or the transmission of the update message is the external tool
  • a transfer control step for suppressing the transfer when the update authority information does not indicate that it is within the authority range.
  • the present invention it is possible to reduce the risk that the firmware of all ECUs is illegally rewritten when confidential information assigned to an external tool is leaked, and allow the external tool to update data in the ECU.
  • FIG. 1 is an overall configuration diagram of an in-vehicle network system according to Embodiment 1.
  • FIG. It is a figure which shows the format of the data frame prescribed
  • 1 is a configuration diagram of a master ECU (update management device) according to Embodiment 1.
  • FIG. 6 is a diagram showing level information according to Embodiment 1.
  • FIG. It is a block diagram of ECU.
  • FIG. 15 It is a figure which shows a 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 (continuing from FIG. 11). It is a whole block diagram of the vehicle-mounted network system which concerns on Embodiment 2.
  • FIG. It is a figure which shows the level information which concerns on Embodiment 2.
  • FIG. 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 (continuing from FIG. 15).
  • FIG. 15 It is a figure which shows a 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 (continuing from FIG. 11). It is a whole block diagram
  • FIG. 9 is a configuration diagram of a master ECU (update management device) according to a third embodiment. It is a figure which shows the information which matched the shared key which concerns on Embodiment 3, and an expiration date.
  • FIG. 10 is a diagram illustrating an example of a screen that prompts an update of a shared key according to the third embodiment. 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 (continuing from FIG. 20). It is a figure which shows the log information which the server which concerns on Embodiment 4 hold
  • An update management method is an update management method used in an in-vehicle network system including a plurality of electronic control units that perform communication via a bus and to which an external tool is connected.
  • the update authority information indicating the authority
  • the update message instructing the update of the data held by one or more of the electronic control units is transmitted from the external tool
  • the verification is successful.
  • 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.
  • an update management method for inhibiting the update corresponding to the update message by said one or more electronic control units for inhibiting the update corresponding to the update message by said one or more electronic control units.
  • the authority to transmit an update message instructing the update of data in the ECU can be determined differently for each external tool based on the verifiable update authority information.
  • the external tool which has the authority to transmit about the update message of the data in some ECUs in a vehicle-mounted network system can update the data in the some ECUs.
  • the ECUs other than some of the ECUs cannot be rewritten illegally. For this reason, it is possible to reduce the risk that the firmware and the like of all ECUs in the in-vehicle network are illegally rewritten, and allow the external tool to update the data in the ECU.
  • the plurality of electronic control units may communicate via the bus according to a Controller Area Network (CAN) protocol, and the external tool may transmit the update message according to the CAN protocol.
  • CAN Controller Area Network
  • the data in the ECU can be updated by an external tool appropriately authorized in the in-vehicle network system according to CAN.
  • the update message when the update message is transmitted from the external tool, whether the update authority information indicates that transmission of the update message is within the authority range of the external tool based on the message ID of the update message If the update authority information indicates that the transmission of the update message is within the authority range of the external tool, the update message having the message ID is determined to be received.
  • the update may be executed by the electronic control unit. Thereby, it is discriminated whether or not the ECU is the target of the update instruction in the update message based on the CAN frame ID (message ID). For this reason, the authority to update specific one or more ECUs can be distinguished from the authority to update other one or more ECUs. For example, the authority according to the ECU that is the target of the update instruction It is possible to allow the update only to the appropriate external tool that it has.
  • the update authority information identifies one or more function types among the plurality of function types for classification of the electronic control unit, and is classified into any one of the identified one or more function types.
  • the update message is transmitted from the external tool, the message ID is received based on the message ID of the update message.
  • Performing the determination by determining whether or not the function type of the electronic control unit determined to match one of the one or more function types specified by the update authority information. It is also good. Thereby, for each function type that classifies the ECU in terms of function, an operation that distinguishes the authority to update and recognizes it as an external tool is possible.
  • This authorization is performed, for example, by providing update authority information that can be verified.
  • the update authority information indicates one level among a plurality of levels for specifying one or a plurality of the function types, and a relatively high level is one or more specified by a relatively low level.
  • a plurality of function types including a plurality of function types may be specified. This makes it possible to change the level of authority for updating for each external tool. For example, an ECU other than the function type of the ECU that can be updated in response to leakage of confidential information about an external tool having a low level of authority (ie, an ECU that can be updated by an external tool having a high level of authority) ) Cannot be rewritten illegally.
  • the update management apparatus that is one electronic control unit receives the update authority information from the external tool connected to the diagnostic port connected to the update management apparatus, performs the verification, and performs the verification from the external tool.
  • the update message is transmitted, the update message is received.
  • the verification is successful, and the update authority information indicates that the transmission of the update message is within the authority range of the external tool.
  • the update authority information is transferred 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, It is also possible to suppress forwarding. Thereby, since an update management apparatus (master ECU) controls whether an update message is transferred to other ECUs, other ECUs can omit the inspection related to the authority of the external tool.
  • the update management apparatus receives the update authority information. Is received by receiving a 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 predetermined encryption processing may be encrypted with the public key of the external tool and transmitted to the external tool.
  • the authority to update the external tool can be certified by issuing a public key certificate.
  • the update management device suppresses transfer of the update message to the bus when the vehicle equipped with the in-vehicle network system is not in a predetermined state. It's also good. As a result, for example, when the vehicle is stopped or the engine is stopped as the predetermined state, data in the ECU is updated in a vehicle stop state where the load on the ECU related to traveling is reduced and bus traffic is relatively low. Therefore, for example, the possibility of a problem in updating can be reduced.
  • the update management device updates the update when a battery that supplies power to each electronic control unit in the in-vehicle network system does not have a predetermined remaining battery level. It is also possible to suppress the transfer of messages to the bus. Accordingly, if a sufficient amount is set as the predetermined battery remaining amount, for example, sufficient for the remaining amount of the battery to be updated, it is possible to prevent a problem due to the battery running out during the update.
  • the electronic control unit other than the update management apparatus and the update management apparatus hold a shared key shared between them for use in transmitting a session key for cryptographic processing related to communication contents, and the update message is
  • the update of the data held by the electronic control unit that is instructed may be an update of the shared key.
  • the shared key shared between the master ECU and the other ECUs can be updated by the external tool.
  • warning information for prompting the renewal of the shared key may be output before a predetermined period of the expiration date of the shared key. As a result, key renewal can be prompted before the expiration date of the shared key, and the risk that the shared key can continue to be used after the expiration date can be reduced.
  • the update management device may transmit identification information for identifying the in-vehicle network system among a plurality of in-vehicle network systems and result information indicating a processing result of the update message to the external tool. Thereby, it becomes possible to manage the update result of the data in ECU for every vehicle (that is, every vehicle-mounted network system) on the external tool side.
  • the external tool may transmit the result information and the identification information to a server. Thereby, it becomes possible to manage the update result of the data in ECU for every vehicle in a server.
  • the update of the data held by the electronic control unit indicated by the update message may be a firmware update of the electronic control unit.
  • the authority for updating the ECU firmware can be flexibly set for each external tool.
  • An update management apparatus is an update management apparatus 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, and updating of data held by the one or more electronic control units.
  • a receiving unit that receives an instructing update message; a verification unit that verifies the update authority information received by the receiving unit; and the verification by the verification unit when the update message is received by the receiving unit.
  • the update authority information indicates that the update message has been successfully transmitted and that the transmission of the update message is within the authority range of the external tool.
  • An update management device comprising a transfer unit that suppresses the transfer.
  • a control program provides an update management apparatus having a processor as one electronic control unit connected to a diagnosis port in an in-vehicle network system including a plurality of electronic control units that perform communication via a bus.
  • An update authority information receiving step for receiving the update authority information to be shown, a verification step for verifying the update authority information received in the update authority information receiving step, and a transmission from the external tool via the diagnostic port, 1
  • An update message for instructing update of data held by one or more of the electronic control units
  • the update message is received at the update message reception step and the update message reception step is received, the verification at the verification step is successful, and the transmission of the update message is within the authority range of the external tool.
  • the update authority information indicates that the update message is transferred to the bus and the verification in the verification step fails, or the transmission of the update message is within the authority range of the external tool.
  • the transfer control step for suppressing the transfer.
  • the master ECU 100 authenticates the external tool 30 and satisfies the predetermined condition only when the external tool 30 is satisfied. Shows an example of permitting updating of ECU data (firmware or the like).
  • FIG. 1 is a diagram illustrating an overall configuration of an in-vehicle network system 10 according to the first embodiment.
  • an external tool 30 is shown in FIG.
  • This external tool 30 represents each of various external tools (for example, external tools 30a and 30b to be described later) manufactured by an operator who manufactures and maintains various ECUs, for example.
  • the in-vehicle network system 10 is an example of a network communication system that performs communication according to a CAN protocol, and is a network communication system in an automobile (vehicle) in which various devices such as a control device and a sensor are mounted.
  • the in-vehicle network system 10 includes a plurality of devices (nodes) that perform communication related to a frame via a bus according to the CAN protocol, and uses an update management method.
  • the in-vehicle network system 10 includes an ECU 400a connected to a diagnostic port 600, buses 500a to 500d, a master ECU (update management device) 100, a head unit 200, a gateway 300, and various devices. And 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, the description will be given with a focus on the master ECU 100 and the ECUs 400a to 400f for convenience.
  • the ECU is a device including, for example, a processor (microprocessor), a digital circuit such as a memory, an analog circuit, a communication circuit, and the like.
  • the memory is a ROM, a RAM, or the like, and can store a control program (computer program) executed by the processor. For example, when the processor operates according to the control program, the ECU realizes various functions.
  • the computer program is configured by combining a plurality of instruction codes indicating instructions for the processor in order to achieve a predetermined function.
  • the diagnostic port 600 is a port for connecting the external tool 30 when maintenance of the ECU configuring the in-vehicle network system 10 is performed, and is connected to the master ECU 100 via a bus 500d.
  • the diagnostic port 600 is a connector compliant with, for example, OBD2.
  • the external tool 30 can transmit a frame according to the CAN protocol to the in-vehicle network system 10 by connecting to the diagnostic port 600.
  • the external tool 30 receives a message including a message ID within a certain range predetermined 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 the failure of the ECU. Can be sent.
  • the external tool transmits an update message (that is, an update request frame) including a predetermined range of message IDs for updating each of the ECU firmware and the shared key. I will explain.
  • the master ECU 100 authenticates the external tool 30, and permits an update message from the external tool to be updated based on the update authority information described in the certificate of the external tool 30 (a public key certificate described later). It is a kind of ECU as an update management device having a role of performing a determination on whether or not.
  • the master ECU 100 is used to transmit a session key for cryptographic processing related to communication contents in a frame between each of one or more ECUs other than its own device among a plurality of ECUs in the in-vehicle network system 10. The same shared key shared in advance is held, and the session key is transmitted 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 (such as the engine 310), and periodically transmits a frame representing 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 a vehicle driver.
  • 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. It has the function to do. It is also possible to switch whether the received frame is transferred or not for each connected bus.
  • the gateway 300 is a kind of ECU.
  • each ECU including the master ECU 400 exchanges frames via the bus.
  • Frames in the CAN protocol include a data frame, a remote frame, an overload frame, and an error frame.
  • the data frame will be mainly described here.
  • FIG. 2 is a diagram showing a data frame format defined by the CAN protocol.
  • a data frame in a standard ID format defined by the CAN protocol is shown.
  • the data frame includes an 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.
  • SOF is composed of 1-bit dominant. When the bus is idle, it is recessive, and the start of frame transmission is notified by changing to dominant by SOF.
  • the ID field is a field for storing an ID (that is, a message ID) that is a value indicating the type of data, which is composed of 11 bits.
  • RTR is a value for identifying a data frame and a remote frame, and is composed of a dominant 1 bit in the data frame.
  • IDE and “r” are both composed of dominant 1 bit.
  • DLC is composed of 4 bits and is a value indicating the length of the data field. 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 composed of a maximum of 64 bits. The length can be adjusted every 8 bits.
  • the specification of the data to be sent is not defined by the CAN protocol, but is defined in the in-vehicle network system 10. Therefore, the specification depends on the vehicle type, manufacturer (manufacturer), and the like.
  • CRC sequence consists of 15 bits. It is calculated from the transmission values of the SOF, ID field, control field and data field.
  • CRC delimiter is a delimiter representing the end of a CRC sequence composed of 1-bit recessive.
  • the CRC sequence and the CRC delimiter are collectively referred to as a CRC field.
  • ACK slot consists of 1 bit.
  • the transmitting node performs transmission with the ACK slot being recessive.
  • the receiving node transmits an ACK slot as a dominant if reception is successful up to the CRC sequence. Since dominant is given priority over recessive, if the ACK slot is dominant after transmission, the transmitting node can confirm that any receiving node has received successfully.
  • ACK delimiter is a delimiter representing the end of ACK composed of 1-bit recessive.
  • EOF is composed of 7 bits recessive and indicates the end of the data frame.
  • FIG. 3 is a diagram showing a key issuing system related to the ECU and the external tool described above.
  • the key issuing organization 20 distributes the public key certificates 40a to 40c, the private keys 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.
  • the manufacturer 21 is, for example, an OEM manufacturer (Original Equipment Manufacturer), an ECU vendor, or the like.
  • the public key certificate describing the public key and the private key are used in a public key infrastructure (PKI), and the public key and the private key are a key pair such as elliptical encryption or RSA encryption.
  • PKI public key infrastructure
  • the shared key 60 representatively represents each shared key.
  • the shared key 60 is a common encryption key AES (Advanced Encryption Standard) key, and is shared between the master ECU 100 and other ECUs, and is used to transmit a session key for cryptographic processing related to the frame.
  • AES Advanced Encryption Standard
  • As encryption processing related to the frame in addition to encryption and decryption of the contents of the data field of the frame, for example, a message authentication code (MAC) is generated in the data field of the frame on the transmission side of the frame. In addition, a process of verifying the MAC on the receiving side can be given. This MAC makes it possible to detect data tampering.
  • the session key is used for generating a MAC, for example.
  • 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
  • the master ECU 20 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.
  • the level of the update authority information described in the public key certificate 40a is 3, and the level of the update authority information described in the public key certificate 40b is 4.
  • FIG. 4 is a diagram showing an example of the configuration of a public key certificate 40a that is issued or distributed by the key issuing institution 20 for writing to the external tools 30a and 30b.
  • the public key certificate 40b has a similar configuration.
  • a public key certificate includes a version, an issuer, start and end of a validity period, certificate identification information (ID), public key, update authority information (level), and a signature for them. Composed.
  • the signature is given by the key issuing organization 20 or a certificate authority such as a portal server. Therefore, the master ECU 100 can authenticate the external tool 30 by acquiring a public key certificate from the external tool 30 and verifying the signature.
  • the authority to transmit an update message instructing the external tool 30 (external tools 30a, 30b, etc.) to update the data in the ECU for any type of ECU is recognized. Specifically, it indicates one of the levels divided into a plurality of levels for the authority. For this reason, the level of authority authorized by the certificate authority or the like that is the signing entity for the external tool 30 is indicated in the update authority information.
  • the public key certificate 40c written to the master ECU 100 includes elements other than the update authority information in the configuration example shown in FIG.
  • FIG. 5 shows an example of a correspondence relationship between the level (that is, the authority level) as the content of the update authority information described in the public key certificate of FIG. 3 and a plurality of function types for classifying ECU functions.
  • FIG. 5 shows an example of a correspondence relationship between the level (that is, the authority level) as the content of the update authority information described in the public key certificate of FIG. 3 and a plurality of function types for classifying ECU functions.
  • the drive system function is a function related to traveling of the vehicle such as control of an engine, a motor, fuel, a battery, a transmission, and the like.
  • 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 the behavior of the vehicle such as “turn”, “stop”, etc., such as brake and steering.
  • the ECU 400b related to the brake 320 corresponds to the function type of the chassis system function.
  • the body system function is a function related to control of vehicle equipment such as a door lock, an air conditioner, a light, and a blinker.
  • 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 function.
  • 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 keeping function, a collision prevention function, and an air bag.
  • the ECU 400e related to the airbag 350 corresponds to the function type of the safety / comfort function.
  • the ITS (Intelligent Transport System) system function is a function corresponding to an intelligent transportation system such as ETC (Electronic Toll Collection System).
  • the telematics function is a function corresponding to a service using mobile communication.
  • the infotainment function is an entertainment function related to car navigation, audio, and the like.
  • the ECU 400f related to the head unit 200 corresponds to the function type of the infotainment function, for example.
  • the authority level as the content of the update authority information authorized by the certificate authority or the like that is the signing subject of the public key certificate is one of the above-described function types based on the correspondence illustrated in FIG. Alternatively, a plurality of function types are specified. Then, the external tool to which the public key certificate is given is sent to the data (firmware, shared) in the ECU, which is classified into one or a plurality of function types specified by the level of the update authority information. Key), that is, the authority to transmit an update message for updating the firmware or shared key.
  • the public key certificate describing the update authority information indicating any one of the four levels from the highest level 4 to the lowest level 1 is given to each external tool. (That is, written).
  • Individual external tools may have different functions, configurations, and the like. For this reason, for example, considering 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 company that manufactures the external tool, and other various circumstances, Update authority information can be defined. Note that FIG. 5 only shows an example of the level, and the number of level stages, the correspondence between the level and the function type, and the like may be determined differently from this example.
  • a correspondence relationship in which each of a plurality of levels (for example, level 4 and level 2) corresponds to the same function type may be determined. Further, the classification of the function type can be determined so as to be different from the example of FIG.
  • a relatively high level in update authority information specifies a plurality of function types including one or more function types specified by a lower level, that is, a higher level includes a lower level authority. It will be described as being.
  • the correspondence between levels and function types may be determined so that there is no authority inclusion relationship between authority levels.
  • the level of authority authorized for external tools is relatively low, only the update of data in some ECUs not related to vehicle running, behavior, etc. is permitted, and other ECUs It is useful not to update the data inside.
  • the level of authority authorized for the external tool (that is, the level that is the content of the update authority information) is 3, the external tool is assigned to all levels below level 3 (that is, level 1 to level 3). ) It is permitted to update the data in the ECU by transmitting an update message to each ECU classified into the function type corresponding to each.
  • 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 30 A determination is made as to whether or not to permit an update to the update message transmitted by 30. In this determination, the master ECU 100 refers to the level information 1040 determined based on the above-described correspondence between the level and the function type (see FIG. 5). The level information 1040 will be described later with reference to FIG.
  • FIG. 6 is a diagram showing a shared key held by the master ECU 100 and the ECUs 400a to 400f.
  • the shared key 60 described above includes a shared key 60a shared by all ECUs, a shared key 60b shared by the ECU 400f and the master ECU 100, ECUs 400c and 400d, and the master ECU 100, as shown in FIG. Shared key 60c shared by ECU 400a, 400b and master ECU 100, and shared key 60e shared by ECU 400e and master ECU 100.
  • FIG. 7 is a configuration diagram of the master ECU 100.
  • the master ECU 100 includes a transmission / reception unit 101, a key storage unit 102, a determination unit 103, a level information storage unit 104, a frame transmission / reception unit 160, a frame interpretation unit 150, a reception ID determination unit 130, and a reception ID list storage.
  • 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 tool 30 (external tools 30a, 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 transmits an update result by the update message.
  • the key holding unit 102 holds the public key certificate 40c, the secret key 50c, and the shared keys 60a to 60e of the master ECU 100.
  • the key holding unit 102 may hold a MAC key that is used when a MAC is assigned as an encryption process for data in a data frame according to the CAN protocol.
  • a session key used for encryption processing related to communication with the external tool 30 or the like may be held in the key holding unit 102.
  • the session key can also be used for MAC generation.
  • the frame transmission / reception unit 160 transmits / receives a frame according to the CAN protocol to / from the bus 500b. That is, the frames from ECUs 400a to 400f are received and the frames are transmitted to ECUs 400a to 400f. A frame is received from the bus 500b bit by bit and transmitted to the frame interpretation unit 150. Further, the contents of the frame notified from the frame generation unit 120 are transmitted bit by bit to the bus 500b.
  • the frame interpretation unit 150 receives a frame value from the frame transmission / reception unit 160 and interprets the value 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 as the ID field to 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 reception of the frame is stopped (that is, the frame) To cancel the interpretation as).
  • the frame generation unit 120 is notified to transmit an error frame. If the frame interpreter 150 receives an error frame, that is, if it interprets that the value in the received frame is an error frame, then the frame interpreter 150 discards the frame, 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. Judge whether to do. The reception ID determination unit 130 notifies the frame interpretation unit 150 of the determination result. Similarly to the frame interpretation unit 150, the reception ID determination unit 130 also determines whether or not the message ID is a frame to be received, and notifies the determination result to the determination unit 103.
  • the reception ID list holding unit 140 holds a reception ID list that 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 to transmit the error frame.
  • the data is subjected to encryption processing (for example, addition of a MAC corresponding to a session key or the like) to form a frame, and the frame transmission / reception unit 160 is notified and transmitted.
  • 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. If the determination unit 103 succeeds in verifying the public key certificate received from the external tool 30, the external tool 30 has been successfully authenticated. The fact that the determination unit 103 has successfully verified the public key certificate also means that the update authority information has been successfully verified.
  • the determination unit 103 confirms that the update authority information has been successfully verified and that the transmission of the update message is within the authority range of the external tool 30. By determining whether or not the information indicates, it is determined whether or not the update corresponding to the update message is permitted.
  • the message ID of the received update message and the level indicated by the update authority information described in the received public key certificate are compared with level information 1040 (described later) held by the level information holding unit 104. This is done by determining whether or not it corresponds appropriately.
  • 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)
  • the frame generation unit 120 is instructed to generate a new update message that is a frame corresponding to the (original) update message for transfer to another ECU (that is, for transmission to the bus 500b).
  • the new update message generated for transfer by the frame generation unit 120 has the same message ID as the original update message, and the data in the data field of the update message is substantially the same. In the case of application, encryption processing (for example, MAC added to the data) applied 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. Thereby, 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 an allowed update message, the master ECU 100 determines that the update message is To the ECU (that is, to the bus 500b). If 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 a predetermined process according to the frame data received from the bus 500b. For example, when the frame processing unit 110 receives a frame indicating an update result in each ECU by an update message from the bus 500b, the frame processing unit 110 generates a message (frame) having the update result as a content, and transmits and receives To the bus 500d connected to the diagnostic port 600.
  • the level information holding unit 104 holds the level information 1040.
  • FIG. 8 is a diagram illustrating an example of the level information 1040 held by the level information holding unit 104.
  • the level information 1040 is information 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 permit an update message from the external tool 30.
  • Message ID 1041 indicates a message ID of an update message that can be transmitted from the external tool 30.
  • “0x100” to “0x104” are defined as message IDs for the update message for updating the shared key held by the ECU
  • “0x104” is defined as the message ID for the update message for updating the firmware of the ECU. The description will be made assuming that “0x200” to “0x206” are defined.
  • Level 1042 indicates the level of authority necessary for transmitting the update message with the corresponding message ID. This level corresponds to the level as the contents of the update authority information. For example, if the value of the level indicated by the update authority information described in the public key certificate of the external tool 30 indicates a value indicating the authority equal to or higher than the value of the level 1042, it is associated with the value of the level 1042. The external tool 30 has the authority to transmit the update message with the received message ID 1041. Conversely, if the value of the level indicated by the update authority information described in the public key certificate of the external tool 30 is a value indicating an authority lower than the value of the level 1042, the message ID 1041 associated with the level 1042 is displayed. The external tool 30 does not have the authority to transmit the update message.
  • the message ID “0x100” shown in FIG. 8 is a message ID regarding an update message for updating the shared key 60a held by the master ECU 100 and the ECUs 400a to 400f.
  • the value of the level 1042 corresponding to this message ID “0x100” is set to 4 which is the highest. This 4 is the value of the highest level (specifically, the level corresponding to the safety / comfort function that is the function type of the ECU 400e) among the levels corresponding to the function type of each ECU that is the target of updating 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 the level 1042 is set to 4.
  • the message ID “0x102” is a message ID for an update message for updating the shared key 60d held by the master ECU 100 and the ECUs 400a and 400b.
  • the value of the level 1042 is set to 3 corresponding to the ECU 400a having the drive system function and the ECU 400b having the chassis system function.
  • the message ID “0x103” is a message ID for an update message for updating the shared key 60c held by the master ECU 100 and the ECUs 400c and 400d.
  • the value of the level 1042 is set to 2 corresponding to the ECUs 400c and 400d having the body functions.
  • the message ID “0x104” is a message ID for an update message for updating the shared key 60b held by the master ECU 100 and the ECU 400f.
  • the value of the level 1042 is set to 1 corresponding to the ECU 400f having the infotainment function.
  • the message ID “0x200” is a message ID for an update message for updating the firmware of the master ECU 100.
  • the value of the level 1042 corresponding to this message ID is set to 4 which is the highest level by specially handling the master ECU 100.
  • the message ID “0x201” is a message ID for an update message for updating the firmware of the ECU 400e.
  • the value of the level 1042 corresponding to this message ID is set to 4 corresponding to the ECU 400e having the safety and comfort function.
  • the message ID “0x202” is a message ID for an update message for updating the firmware of the ECU 400b.
  • the level 1042 value 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 the level 1042 corresponding to this message ID is set to 3 corresponding to the ECU 400a having the drive system function.
  • the message ID “0x204” is a message ID for an update message for updating the firmware of the ECU 400c.
  • the value of level 1042 corresponding to this message ID is set to 2 corresponding to ECU 400c having a body system function.
  • Message ID “0x205” is a message ID for an update message for updating the firmware of ECU 400d.
  • the value of level 1042 corresponding to this message ID is set to 2 corresponding to ECU 400d having a body function.
  • the message ID “0x206” is a message ID for an update message for updating the firmware of the ECU 400f.
  • the value of the level 1042 corresponding to this message ID is set to 1 corresponding to the ECU 400f having the infotainment function.
  • FIG. 9 is a configuration diagram of the ECU 400a.
  • the ECU 400a includes a key storage unit 402, a frame transmission / reception unit 460, a frame interpretation unit 450, a reception ID determination unit 430, a reception ID list storage unit 440, a frame processing unit 410, a frame generation unit 420, and data acquisition. 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 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 a MAC key used when MAC is assigned as encryption processing to data in a data frame according to the CAN protocol. Further, a session key used for encryption processing related to communication with other ECUs or the like may be held in the key holding unit 402. The session key can also be used for MAC generation.
  • the frame transmission / reception unit 460 transmits / receives a frame according to the CAN protocol to / from the bus 500a.
  • a frame is received bit by bit from the bus 500a and transferred to the frame interpreter 450.
  • the content of the frame notified from the frame generation unit 420 is transmitted to the bus 500a.
  • the frame interpretation unit 450 receives a 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 as the ID field is transferred to the reception ID determination unit 430.
  • the value of the ID field (message ID) and the data field appearing after the ID field are transferred to the frame processing unit 410 or received the determination result Thereafter, it is determined whether to stop receiving the frame (that is, stop the interpretation as the frame). If it is determined that the frame does not comply with the CAN protocol, the frame generation unit 420 is notified to transmit an error frame. If the frame interpreter 450 receives an error frame, that is, if it interprets that the value in the received frame is an error frame, the frame interpreter 450 discards the frame thereafter, that is, cancels the interpretation of 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 frames after the ID field according to the list of message IDs held by the reception ID list holding unit 440. Judge whether to do. The reception ID determination unit 430 notifies this determination result to the frame interpretation unit 450.
  • the reception ID list holding unit 440 holds a reception ID list (see FIG. 10) that is a list of message IDs received by the ECU 400a.
  • the frame processing unit 410 performs processing related to different functions for each ECU according to the received frame data.
  • ECU 400a connected to engine 310 can perform predetermined control according to the relationship between the rotational speed of engine 310 and the state of a part of the vehicle indicated by frame data received from another ECU.
  • the data acquisition unit 470 acquires data indicating the state of devices and sensors 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 to transmit the error frame. Also, the frame generation unit 420 composes a data frame by adding a predetermined message ID to the value of the data field determined based on the data notified from the data acquisition unit 470, and notifies the frame transmission / reception unit 460 of the data frame. To send. Note that the frame generation unit 420 can add the MAC generated using the MAC key or the session key to the value of the data field.
  • 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 in FIG. 10 indicates 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 IDs of the messages (frames) received by the ECU 400a are not limited to “0x102” and “0x203”. In the example of FIG.
  • 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 messages that can be received by the master ECU 100 are listed in the same manner as the reception ID list 900.
  • 11 and 12 are diagrams showing an example of a shared key update sequence performed among the external tool 30a, the master ECU 100, and the ECU 400a.
  • the external tool 30a as one of the external tools 30 and the ECU 400a that is one of the ECUs 400a to 400f will be described.
  • a description will be given assuming that the external tool 30a is used to update the shared key held by each ECU having the drive system function and the chassis system function.
  • an update message with a message ID “0x102” for updating the shared key 60d held by each of the ECU 400a having the drive system function and the ECU 400b having the chassis system function is sent from the external tool 30a to the in-vehicle network system. 10 will be transmitted. Since the operation of the ECU 400b is similar to the operation of the ECU 400a, the description thereof is omitted here.
  • the external tool 30a buses the certificate (that is, the public key certificate 40a held by the external tool 30a).
  • an authentication request is transmitted to ECU 100 for communication connection (step S1001).
  • the external tool 30a can transmit an update message for updating data (shared key, firmware) in the ECU of the in-vehicle network system 10 in accordance with, for example, a user operation.
  • an authentication request certificate
  • 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).
  • the signature by the certificate authority is verified, and further, the private key corresponding to the public key described in the public key certificate 40a by the challenge response (CR) authentication method is used as the external tool 30a.
  • the master ECU 100 transmits a random number to the external tool 30a, and when the external tool 30a returns an encrypted random number, which is a result of encrypting the random number with a secret key, to the master ECU 100, the master ECU is disclosed.
  • 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 permitted, and the external tool 30a cannot update the ECU data by transmitting an update message, for example. Note that the master ECU 100 may or may not return a response to the external tool 30a as error processing.
  • the master ECU 100 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 a random number (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 the MAC to the data in the update message, the session key generates the MAC. Used as a key to
  • step S1004 the transmission / reception unit 101 of the master ECU 100 encrypts the session key with the public key of the external tool 30a, and obtains the encrypted session key as a result of the encryption and the public key certificate 40c of the master ECU 100. It transmits 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 obtain the session key (step S1004). S1008).
  • the external tool 30a After step S1008, the external tool 30a generates an update message for updating the shared key 60d with the message ID “0x102”, and performs an encryption process on the update message using the session key (step S1009). ).
  • data necessary for updating the shared key 60d is stored in the data field (for example, data that becomes a key when the ECU 400a is updated by a keyed hash function or the like). And encrypting the data or adding a MAC to the data. Even when data is not required for updating the shared key 60d, for example, the MAC corresponding to the whole or a part of the update message can be stored in the data field.
  • a predetermined cryptographic process to be performed (that is, a predetermined cryptographic process using a session key) to be performed is defined in advance as to what kind of processing is performed as the cryptographic process corresponding to the update message.
  • each ECU performs an update in response to an update message in which predetermined encryption processing (for example, addition of MAC) is appropriately performed (that is, verification using a session key is successful) in accordance with the regulations, and the predetermined encryption If the process is not properly implemented, the update message is inhibited from being updated.
  • predetermined encryption processing for example, addition of MAC
  • the external tool 30a transmits the update message generated in step S1009 to the master ECU 100 (step S1010).
  • the determination unit 103 determines whether or not the message ID of the message (frame) received by the transmission / reception unit 101 of the master ECU 100 is an ID to be received by the external tool 30a in step S1010. (Step S1011).
  • the message IDs “0x100” to “0x104” for updating the shared key and the message IDs “0x200” to “0x206” for updating the firmware are determined to be IDs to be received.
  • the description is made on the assumption that the external tool 30a transmits an update message. Therefore, a message (frame) from the external tool 30a is referred to as an update message, but it may not actually be an update message. Since this is possible, the determination is made in step S1011.
  • the master ECU 100 does not handle a 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) connected to the diagnostic port 600. .
  • step S1011 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 process related to the message with the message ID and transmits / receives the transmission / reception unit. In 101, the process ends without receiving the contents (data field, etc.) after the ID field (step S1012).
  • step S1011 when it is determined that the message ID of the message received by the transmission / reception unit 101 is an ID to be received, the determination unit 103 of the master ECU 100 determines the message ID “0x102” of the received message and the external tool 30a. Depending on whether or not the level of the update authority information described in the public key certificate 40a matches the correspondence between the message ID 1041 and the level 1042 in the level information 1040 held in the level information holding unit 104 It is determined whether or not the received message is a 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.
  • step S1014 If the received message is not an allowed update message, error processing is performed (step S1014).
  • the update corresponding to the update message is suppressed by the error processing in step S1014.
  • the determination unit 103 determines that the update message received from the external tool 30a is a permitted update message.
  • 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 a permitted update message), the determination unit 103 The generation unit 120 is instructed to generate a transfer update message (step S1015).
  • a transfer update message (step S1015)
  • a new update message (frame) for transfer to the bus 500b (that is, transfer to another ECU).
  • frame generation is performed.
  • unit 120 performs decryption using the session key for communication with external tool 30a, and uses the result of the process for communication with another ECU.
  • a new update message is generated by performing encryption using the session key.
  • the frame generation unit 120 generates a MAC using a session key used for communication with another ECU, and generates the MAC of the original update message. Is replaced with the generated MAC to generate a new update message. In this case, error processing may be performed when the MAC of the original update message is verified and the verification fails. Further, for example, when the session key used for communication with the external tool 30a by the master ECU 100 is the same as the session key used for communication with another ECU, the frame generation unit 120 uses the original update message and Generate the same new update message.
  • the frame transmission / reception unit 160 sends the update message generated by the frame generation unit 120 of the master ECU 100 to the bus 500b (step S1016). That is, when the update message is transmitted from the external tool 30a, the master ECU 100 has successfully verified the update authority information (that is, the verification of the public key certificate), and has transmitted the update message to the external tool 30a. When the update authority information indicates that it is within the authority range, the update message is transferred to the bus 500b. When the verification of the update authority information has failed or when the update authority information does not indicate that the update message transmission is within the authority range of the external tool 30a, the update message is transferred to the bus 500b. I will not.
  • the update authority information that is, the verification of the public key certificate
  • 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.
  • the ECUs 400a to 400f can receive the update message.
  • the master ECU 100 determines that the update authority information indicates that the transmission of an update message with a message ID is within the authority range of the external tool 30a, it is predetermined to receive the update message with the message ID.
  • An update corresponding to the update message can be executed by the existing ECU.
  • the frame transmission / reception unit 460 receives the update message, the frame interpretation unit 450 interprets the content of the message, and inquires of the reception ID determination unit 430 whether there is an ID to be received.
  • 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 an ID to be received (step S1017).
  • the frame interpretation unit 450 relates to the received message.
  • the processing is stopped, and the frame transmission / reception unit 460 ends the processing without receiving the contents after the ID field (step S1018).
  • the ECU 400a causes the frame processing unit 410 to execute the message. Processing corresponding to (that is, update message) (that is, updating of shared key 60d) is executed (step S1019).
  • a new shared key 60d to be updated is obtained from the shared key 60d currently held by the key holding unit 402 by using a key function in the data field of the update message by a keyed hash function. Generate.
  • ECU 400a processing (decryption or MAC verification) corresponding to encryption processing (encryption or MAC addition) performed on the update message is performed using the session key, and key data of the update message is acquired.
  • the ECU 400a sends a message indicating the result of the update (referred to as an update result message) to the master ECU 100 after the update of the shared key 60d to the bus 500a (S1020).
  • the message ID of the update result message is determined in advance, 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, a successful update). When an error occurs during the update (for example, when the key data MAC verification 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.
  • the master ECU 100 updates the shared key 60d held by the key holding unit 102 (see FIG. 6) in the same manner as the ECU 400a (step S1021).
  • the master ECU 100 holds the key holding unit 102 only when, for example, both the update result message indicating the successful update from the ECU 400a and the update result message indicating the successful update from the ECU 400b are received.
  • 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).
  • 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 of the completion of the update (for example, the external tool 30a has a display device). If it does, it can be displayed).
  • 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 described.
  • Each device performs the same operation even when an update message for updating firmware in the ECU is transmitted.
  • the external tool 30a may sequentially transmit each update message after transmitting the authentication request once. In this case, after the processing from step S1001 to step S1008 is executed once, each time the external tool 30a transmits each update message, the processing after step S1009 is repeated.
  • the update message for updating the firmware in the ECU includes, for example, information for specifying the content of the updated firmware, and the ECU that is the target of the update message specifies the content of the updated firmware.
  • the firmware is rewritten based on the information.
  • the firmware includes, for example, software such as a program in the ECU and data used in the program, and may include, for example, microcode in a processor in the ECU.
  • the firmware may include data for circuit configuration when the ECU includes, for example, an FPGA (Field Programmable Gate Array).
  • FPGA Field Programmable Gate Array
  • the level of update authority information can be set (and certified) depending on, for example, the confidentiality and reliability of the external tool, the reliability of the operator handling the external tool, and other various circumstances. It is also possible to distribute external tools with different levels to different maintenance companies, etc., and it becomes possible to operate with limited update authority flexibly according to various circumstances. For example, an external tool with sufficient security such as confidentiality and reliability can recognize a higher authority level.
  • the ability to set the level of update authority information for each external tool in this way is used to efficiently and flexibly design and manufacture the external tool according to the application, etc., or to ensure security in the operation of the external tool. It is useful to perform flexibly according to the situation.
  • the master ECU 100 authenticates the external tool 30, and the update message from the external tool 30 is updated update information.
  • the external tool 30 is allowed to update the data in the ECU with the update message only when it is within the range of authority (level) to be shown.
  • the in-vehicle network system 10a not only the level but also the state of the vehicle in which the in-vehicle network system 10a is mounted, and the battery in the vehicle, in determining whether or not to permit the update message of the external tool 30 Refer to the status of the remaining amount.
  • the configuration of the in-vehicle network system 10a according to the present embodiment is substantially the same as that of the in-vehicle network system 10 (see FIG. 1) shown in the first embodiment, and hereinafter, the same reference numerals are used for the same components as in the first embodiment. .
  • FIG. 13 is a diagram showing an overall configuration of the in-vehicle network system 10a according to the second embodiment.
  • an external tool 30 is shown in addition to the in-vehicle network system 10a.
  • a storage battery 800 and an ECU 400g are added to the in-vehicle network system 10 (FIG. 1).
  • description of the same components as those in the first embodiment is omitted.
  • the ECU 400g is connected to the bus 500b, performs control related to charging / discharging of the battery (storage battery) 800, acquires and manages the remaining amount of the storage battery 800, and periodically displays a frame indicating the remaining battery state on the network (that is, To the bus 500b).
  • the storage battery 800 supplies power to each ECU in the in-vehicle network system 10.
  • FIG. 14 is a diagram illustrating an example of level information 2040 held by the level information holding unit 104 of the master ECU 100 according to the second embodiment.
  • the level information 2040 is information in which the message ID 2014, the level 2042, the remaining 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 permit an update message from the external tool 30. Used.
  • the message ID 2041 and the level 2042 are the same as the message ID 1041 and the level 1042 described in the first embodiment.
  • the battery remaining amount condition 2043 indicates the condition of the remaining amount of battery required for permitting the update message. For example, the remaining amount of battery is set to an amount sufficient for the update. With the fully charged amount as 100%, either a remaining amount of 50% or more of charging or a remaining amount of 80% or more of charging is set.
  • the vehicle state condition 2044 indicates a vehicle state condition required for permitting the update message. For example, the vehicle state condition (state where the vehicle speed is zero) and the engine OFF state (engine 310 is stopped). Is set).
  • the update message for updating the shared key with the message ID “0x104” has an update authority information level of 1 or higher, the remaining battery level of the storage battery 800 is 50% or more, and the vehicle state is stopped. Indicates that it is allowed when The update message for updating the firmware with the message ID “0x201” is when the level of update authority information 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.
  • 15 and 16 are diagrams illustrating an example of a shared key update sequence performed among the external tool 30a, the master ECU 100, and the ECU 400a.
  • the external tool 30a as one of the external tools 30 and the ECU 400a that is one of the ECUs 400a to 400g will be described. Further, a description will be given assuming that the external tool 30a is used to update the shared key held by each ECU having the drive system function and the chassis system function.
  • an update message with a message ID “0x102” for updating the shared key 60d held by each of the ECU 400a having the drive system function and the ECU 400b having the chassis system function is sent from the external tool 30a to the in-vehicle network system. 10 will be transmitted.
  • step S2001 to step S2012 and from step S2014 to step S2022 is equivalent to the processing from step S1001 to step S1012 and from step S1014 to step S1022 shown in the first embodiment (see FIGS. 11 and 12).
  • the description is omitted, and only steps S2013a to S2013c different from the first embodiment will be described here.
  • 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 for the authority level as an appropriate update message depending on whether or not the correspondence between the message ID 2041 and the level 2042 in the level information 2040 that has been set matches. 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 for the authority level, error processing is performed (step S2014).
  • 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 moves the process to the next step S2013b.
  • step S2013b the determination unit 103 checks whether the remaining battery level of the storage battery 800 satisfies a condition.
  • the ECU 400g that manages the remaining battery level of the storage battery 800 periodically transmits a message indicating the remaining battery level (referred to as a remaining battery frame)
  • the master ECU 100 displays the remaining battery frame from the ECU 400g. Received by the frame transmission / reception unit 160. Note 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 amount frame from the ECU 400g.
  • the determination unit 103 checks whether or not the remaining battery level indicated by the remaining battery level frame received from the ECU 400g satisfies the remaining battery level condition 2043 corresponding to the message ID 2041 held in the level information holding unit 104. If the remaining battery condition is satisfied, the process proceeds to the next step S2013c. If the condition of the remaining battery level is not satisfied (that is, if the result of the check is NG), error processing is performed (step S2014). Note that the ECU 400g may not periodically transmit the remaining battery level frame indicating the remaining battery level. In this case, in step S2013b, the master ECU 100 requests the ECU 400g to transmit the remaining battery level frame, for example. By transmitting the frame, the battery remaining amount frame may be received from the ECU 400g, and the state of the remaining battery amount when the update message is received (that is, current) may be acquired.
  • step S2013c the determination unit 103 checks whether the vehicle state satisfies a condition.
  • ECU 400a associated with 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
  • master ECU 100 transmits the vehicle state frame from ECU 400a to a frame transmission / reception unit. Receive at 160. It is assumed that the reception ID list held by 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 condition of the vehicle state is satisfied, the determination unit 103 determines that the update message received from the external tool 30a is permitted, and moves the process to step S2015. If the vehicle condition is not satisfied (that is, if the result of the check is NG), error processing is performed (step S2014). The ECU 400a may not periodically transmit the vehicle state frame.
  • step S2013c the master ECU 100 transmits a frame requesting the ECU 400a to transmit the vehicle state frame, for example, from the ECU 400a.
  • 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).
  • 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 the components of the master ECU 100 shown in the first embodiment in order to check the expiration date of the shared key.
  • Each of these components is a functional component, and each function is realized by a communication circuit in the master ECU 100a, a processor that executes a control program stored in a memory, a digital circuit, or the like.
  • the description of the components shown in the first embodiment is omitted.
  • the time information acquisition unit 180 is configured by a timekeeping mechanism such as a real time clock, for example, and acquires the current time (that is, the current date and time) and sequentially notifies the key update confirmation unit 190.
  • a timekeeping mechanism such as a real time clock, for example, and acquires the current time (that is, the current date and time) and sequentially notifies the key update confirmation unit 190.
  • the key update confirmation unit 190 confirms the current time notified from the time information acquisition unit 180 and the expiration date set in advance for the shared key held by the key holding unit 102, and is set in advance as an alert notification timing. At a point in time when a certain timing has passed (that is, before a fixed period of the expiration date), the key update alert message is generated by the frame generation unit 120 and transmitted from the frame transmission / reception unit 160.
  • FIG. 18 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 other for each shared key 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 an expiration date determined in advance for ensuring the security of the shared key indicated by the corresponding shared key identification information.
  • the alert notification timing 3312 indicates the 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, in the case of the shared key 60a, a key update alert message is transmitted from three months before the expiration date, and in the case of the shared key 60d, a key update alert message is transmitted from one month before the expiration date.
  • the key update alert message is received by the ECU 400f connected to the head unit 200.
  • the ECU 400f displays warning information (screen) prompting the renewal of the shared key indicating that the expiration date of the shared key is approaching on the display device of the head unit 200.
  • FIG. 19 is a diagram illustrating an example of a screen displayed on the display device of the head unit 200 when the expiration date of the shared key approaches.
  • the screen 3320 includes the current date and time and the expiration date of the shared key of the ECU. Further, the contact information of the maintenance company (dealer in this example) for updating the shared key, the website Contains URL (Uniform Resource Locator).
  • the screen 3320 includes a GUI (Graphical User Interface) button 3321 for transitioning to a screen for setting the destination to the dealer's address by the navigation system.
  • the dealer information may be registered in advance in the master ECU 100a at the time of sale, for example, or may be acquired via an ECU having a telematics function.
  • the dealer or the like may use the external tool 30 as described in the first and second embodiments. Can be used to update the shared key held by the ECU in the in-vehicle network system.
  • Embodiment 3 In the in-vehicle network system according to Embodiment 3, the expiration date of the shared key is managed, and when the expiration date approaches, warning information (screen) that prompts the driver of the vehicle to update the key is displayed on the head unit. Display on the display device. As a result, alerting for ensuring the security related to the shared key, such as a warning to receive maintenance at a dealer or the like, is realized.
  • the master ECU 100 in the in-vehicle network system 10 according to the first embodiment is modified so that vehicle update information is attached to the update result message and transmitted to the external tool 30, and the external tool 30 is connected to the server 35.
  • vehicle update information is attached to the update result message and transmitted to the external tool 30, and the external tool 30 is connected to the server 35.
  • 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 determines which update (data in the ECU) the external tool 30 has for which vehicle (that is, the in-vehicle network system). (Update) is managed.
  • step S3001 to step S3021 are diagrams illustrating an example of a shared key update sequence performed between the external tool 30a communicating with the server 35, the master ECU 100, and the ECU 400a.
  • the processing from step S3001 to step S3021 is the same as the processing from step S1001 to step S1021 shown in the first embodiment (see FIGS. 11 and 12), and thus the description thereof is omitted.
  • the processing is different from the first embodiment. Only steps S3000a, S3000b, S3022, S3023, and S3024 will be described.
  • step S3000a the external tool 30a issues a connection request to the server 35. That is, the external tool 30a transmits a login request using, for example, a pre-registered ID (for example, a tool ID) and a password to the server 35.
  • a pre-registered ID for example, a tool ID
  • a password for example, a password
  • step S3000b the server 35 receives a connection request from the external tool 30a, performs a login process and returns a normal response if the ID and password match information registered in advance.
  • step S3000b the external tool 30a, the master ECU 100, and the ECU 400a perform processing related to the update of the shared key as described in the first embodiment.
  • step S3020 master ECU100 has received the update result message which shows the update result from ECU400a.
  • step S3022 the master ECU 100 sends an update result message with vehicle identification information, which is a message including the vehicle identification information, to the bus 500d in addition to the update result from the ECU 400a, thereby allowing the external tool 30a to pass through the diagnostic port 600. Send to. Thereby, the external tool 30a receives the update result message with vehicle identification information.
  • vehicle identification information only needs to identify the in-vehicle network system to which the external tool 30a is connected among the plurality of in-vehicle network systems.
  • the vehicle identification information is a public key certificate 40c (see FIG. 3) of the master ECU 100. is there.
  • step S ⁇ b> 3023 the external tool 30 a transmits the vehicle identification information and the update result indicated by the received update result message with vehicle identification information to the server 35.
  • step S3024 the server 35 stores the received vehicle identification information and the update result, the current date and time, and the log information 4000 in association with the ID received at the time of login.
  • FIG. 22 is a diagram illustrating an example of log information 4000 stored by the server 35.
  • the log information 4000 includes vehicle identification information 4001, an external tool ID 4002, an update message message ID 4003, a date and time 4004, and an update result 4005.
  • 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.
  • the log information 4000 can be used for specifying the range of influence by the external tool.
  • Embodiments 1 to 4 have been described as examples of the technology according to the present invention.
  • the technology according to the present invention is not limited to this, and can also be applied to embodiments in which changes, replacements, additions, omissions, etc. are made as appropriate.
  • the following modifications are also included in one embodiment of the present invention.
  • 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 function, it is not limited to this, and the master ECU and one or more other
  • the unit in which the ECU has the shared key can be arbitrarily determined in the in-vehicle network system.
  • the in-vehicle network may be divided into a plurality of domains and a shared key may be set for each domain.
  • the level information may be set by distinguishing the domain as the level of authority required for the update.
  • the external tool 30 has the public key certificate including the update authority information in which the authority level is set based on the function type. However, the update corresponding to the automobile manufacturer and the vehicle type is shown. It is also possible to have a public key certificate including update authority information in which the authority is set.
  • the shared key is updated by generating a new shared key using a keyed hash function from the shared key currently held by each ECU.
  • the tool 30 may send the new shared key itself in the update message. 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.
  • an update message for updating data (shared key, firmware, etc.) in the ECU is transmitted from the external tool 30 is shown. Can be sent.
  • in-vehicle network system for example, master ECU
  • in-vehicle network system may perform processing corresponding to the message without determining the authority based on the level information.
  • authority information indicating an authority level indicating whether the transmission of the message is within the authority range permitted by the external tool 30 in the in-vehicle network system (for example, master ECU). It is good also as judging based on.
  • the authority level is set from 1 to 4, but the level does not have to be four levels, and may be set to be more than that.
  • the method of classifying the function type shown in the above embodiment is merely an example, and may be subdivided in more detail, for example.
  • the function type may be classified most finely, and for example, the authority level related to updating of data in the ECU may be set for each ECU.
  • the battery remaining condition 2043 is distinguished based on the ratio (percentage) of the storage battery 800 with respect to the full charge, but the battery remaining condition 2043 may be distinguished based on 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. Thereby, for example, it is possible to permit a certain shared key and firmware update only during charging.
  • the time information acquisition unit 180 of the master ECU 100a acquires the current time with a timekeeping mechanism in order to confirm that the shared key has expired, but WiFi (registered trademark), mobile phone Time information indicating the current time may be acquired from a telephone carrier network, or time information may be acquired from a GPS (Global Positioning System) signal. Further, the master ECU 100a may acquire time information from another ECU.
  • WiFi registered trademark
  • mobile phone Time information indicating the current time may be acquired from a telephone carrier network
  • time information may be acquired from a GPS (Global Positioning System) signal.
  • GPS Global Positioning System
  • 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.
  • authentication is performed between the external tool 30 and the master ECU.
  • an electronic circuit for example, a memory, a processor, or the like responsible for authentication is provided to the diagnostic port 600 that is a connector or the like compliant with OBD2.
  • the master ECU can omit the authentication of the external tool 30.
  • 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 a connector compliant with OBD2.
  • the diagnostic port 600 including the wireless communication circuit may be realized so that it can be connected to the external tool 30 by wireless communication.
  • the update authority information may indicate not only the authority level but also the conditions for the update authority such as the battery remaining condition and the vehicle state condition described in the second embodiment.
  • the update authority information specifies at least one stop state that is the state of the vehicle as the vehicle state condition or a state in which the engine is stopped, and transmits 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 update the ECU.
  • the update authority information specifies a remaining battery state that supplies power to the ECU as a remaining battery condition, and an update message is displayed when the battery has the specified remaining battery capacity. It is also possible to indicate that the external tool has the authority to update the ECU under the condition that transmission is at least one condition. Then, for example, the master ECU 100 performs a check (steps S2013b and S2013c) based on the battery remaining condition and vehicle state condition indicated by the update authority information instead of the battery remaining condition 2043 and the vehicle state condition 2044 in the level information 2040. You may make it do. This allows the external tool to recognize the authority with a certain condition according to the reliability of the external tool, etc., and to provide the public key certificate with the update authority information indicating the condition and the level of authority. Operation like issuing is possible.
  • the data frame in the CAN protocol is described in the standard ID format, but it may be in the extended ID format.
  • the message ID is represented by 29 bits by combining the base ID at the ID position in the standard ID format and the extended ID.
  • the master ECU updates the update message that is permitted. (Step S1013), if the update message is not permitted, error processing is performed (step S1014), and the update corresponding to the update message is suppressed.
  • an ECU other than the master ECU for example, an ECU to be instructed to update by an update message
  • the gateway 300 manages the function type of the ECU connected to the transfer destination bus or the message ID that can be received by the ECU. When the gateway 300 receives the update message, the gateway 300 connects to the transfer destination bus. An unnecessary update message may not be transferred based on the function type of the ECU or the message ID that can be received by the ECU.
  • the master ECUs 100 and 100 a include a receiving unit corresponding to the receiving function of the transmission / reception unit 101, a verification unit in charge of verifying the public key certificate (public key certificate including update authority information) in the determination unit 103, and the determination unit 103. And a transfer unit that performs control related to transmission of the update message corresponding to a part of the frame generation unit 120 and a part of the frame transmission / reception unit 160.
  • the receiving unit transmits update authority information indicating the authority of the external tool 30 and one or more ECUs transmitted from the external tool 30 connected to the diagnosis port 600 via the diagnosis port 600. Bears the function of receiving an update message instructing to update the data held by.
  • the verification unit has a function of verifying the update authority information received by the reception unit.
  • the transfer unit indicates that the verification by the verification unit is successful and the update authority information indicates that the transmission of the update message is within the authority range of the external tool 30
  • the control program executed by the processor in the master ECU 100, 100a having a processor may be a program for causing the master ECU 100, 100a to execute, for example, the following 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 transmitted from the external tool connected to the diagnostic port, and an update authority information receiving step.
  • the update message receiving step for receiving the update message transmitted from the external tool through the diagnostic port, and the update message receiving step
  • the update message is transferred to the bus for communication with the ECU
  • verification in the verification step fails or the update message is sent by an external tool
  • a transfer control step of inhibiting the transfer When the update authority information does not indicate that it is within the limited range, and a transfer control step of inhibiting the transfer.
  • the master ECU and other ECUs in the above embodiment are devices including a digital circuit such as a processor and a memory, an analog circuit, a communication circuit, and the like.
  • a digital circuit such as a processor and a memory
  • an analog circuit such as a communication circuit, and the like.
  • a hard disk device such as a hard disk device, a display, a keyboard, and a mouse
  • the function may be realized by dedicated hardware (digital circuit or the like).
  • a part or all of the constituent elements constituting each device in the above embodiment may be constituted by one system LSI (Large Scale Integration).
  • the system LSI is an ultra-multifunctional LSI manufactured by integrating a plurality of components on a single chip.
  • the system LSI is a computer system including a microprocessor, a ROM, a RAM, and the like. .
  • a computer program is recorded in the RAM.
  • the system LSI achieves its functions by the microprocessor operating according to the computer program.
  • each part of the constituent elements constituting each of the above devices may be individually made into one chip, or may be made into one chip so as to include a part or the whole.
  • the system LSI is used here, it may be called IC, LSI, super LSI, or ultra LSI depending on the degree of integration.
  • the method of circuit integration is not limited to LSI's, and implementation using dedicated circuitry or general purpose processors is also possible.
  • An FPGA that can be programmed after manufacturing the LSI, or a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used.
  • integrated circuit technology comes out to replace LSI's as a result of the advancement of semiconductor technology or a derivative other technology, it is naturally also possible to carry out function block integration using this technology. Biotechnology can be applied as a possibility.
  • a part or all of the constituent elements constituting each of the above devices may be constituted by an IC card or a single module that can be attached to and detached from each device.
  • the IC card or the module is a computer system including a microprocessor, a ROM, a RAM, and the like.
  • the IC card or the module may include the super multifunctional LSI described above.
  • the IC card or the module achieves its function by the microprocessor operating according to the computer program. This IC card or this module may have tamper resistance.
  • One aspect of the present invention may be an update management method such as the shared key update sequence described above.
  • the present invention may be a computer program that realizes these methods by a computer, or may be a digital signal composed of the computer program.
  • the computer program or the digital signal can be read by a computer, such as a flexible disk, a hard disk, a CD-ROM, an MO, a DVD, a DVD-ROM, a DVD-RAM, and a BD. (Blu-ray (registered trademark) Disc), recorded on a semiconductor memory or the like. Further, the digital signal may be recorded on these recording media.
  • the computer program or the digital signal may be transmitted via an electric communication line, a wireless or wired communication line, a network typified by the Internet, data broadcasting, or the like.
  • an aspect of the present invention may be a computer system including a microprocessor and a memory, in which the memory records the computer program, and the microprocessor operates according to the computer program.
  • the program or the digital signal is recorded on the recording medium and transferred, or the program or the digital signal is transferred via the network or the like and executed by another independent computer system. You may do that.
  • the present invention can be used for managing 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Mechanical Engineering (AREA)
  • Stored Programmes (AREA)
  • Small-Scale Networks (AREA)

Abstract

　車載ネットワークを構成する電子制御ユニット（ＥＣＵ）の共有鍵等を更新する更新メッセージを送信し得る外部ツールに付与された機密情報が漏洩した場合に全てのＥＣＵが不正に書き換えられるリスクを低減して、外部ツールにＥＣＵ内の共有鍵等を更新させるための更新管理方法を提供する。更新管理方法は、外部ツールの権限を示す更新権限情報を受信して検証し、外部ツールから、１つ又は複数のＥＣＵの共有鍵等の更新を指示する更新メッセージが送信された場合（ステップＳ１０１０）において、更新権限情報の検証が成功し、かつ、更新メッセージの送信が外部ツールの権限範囲内であることを更新権限情報が示すときには（ステップＳ１０１３）、ＥＣＵで更新（ステップＳ１０１９）を実行し、それ以外のときにはＥＣＵによる更新を抑止する。

Description

更新管理方法、更新管理装置及び制御プログラム
　本発明は、車載ネットワークシステムにおける電子制御ユニットの保持するデータを更新するための更新管理方法、更新管理装置等に関する。
　近年、自動車の中のシステムには、電子制御ユニット（ＥＣＵ：Electronic Control Unit）と呼ばれる装置が多数配置されている。これらのＥＣＵをつなぐネットワークを車載ネットワークと呼ばれる。車載ネットワークには、多数の規格が存在する。その中でもＩＳＯ１１８９８－１で規定されている、ＣＡＮ（Controller Area Network）という規格が主流である。ＣＡＮでは、通信路は２本のバスで構成され、バスに接続されているＥＣＵはノードと呼ばれる。バスに接続されている各ノードは、フレームと呼ばれるメッセージを送受信する。ＣＡＮでは送信先や送信元を指す識別子は存在せず、送信ノードはフレーム毎にＩＤ（メッセージＩＤと称する）を付けて送信し（つまりバスに信号を送出し）、各受信ノードは予め定められたメッセージＩＤのみを受信する（つまりバスから信号を読み取る）。また、ＣＳＭＡ／ＣＡ（Carrier Sense Multiple Access/Collision Avoidance）方式を採用しており、複数ノードの同時送信時にはメッセージＩＤによる調停が行われ、メッセージＩＤの値が小さいフレームが優先的に送信される。また、車載ネットワークには、ＯＢＤ２（On-Board Diagnostics２）と呼ばれる、外部ツール（例えば故障診断ツール等の外部装置）と通信するインタフェースであるポート（以下、「診断ポート」と称する）が存在し、ＥＣＵの診断に利用される。最近では診断だけでなく、診断ポートを利用してＥＣＵのファームウェアの書き換えも可能になっている。また、診断ポートと接続可能な外部ツールが安価に発売されており、専門業者でなく一般ユーザが使える外部ツールが増えている。
　そのため、不正な外部ツールが診断ポートに接続されるリスクは高まっている。不正な外部ツールにより車載ネットワークにおけるＥＣＵのファームウェアを不正に書き換えることで、車体を不正にコントロールすることが可能になる。このように診断ポート経由で不正なファームウェアの書き換えを防止する方法として、外部ツールが送信するファームウェア更新要求メッセージに識別コードが埋め込まれており、識別コードが登録コードと一致した場合にファームウェアの更新を許可する方法が存在する（特許文献１参照）。
特開２０１３－１４１９４８号公報
　しかしながら、特許文献１の方法には、ファームウェアを更新する外部ツールに付与されている識別コードが漏洩した場合に、全てのＥＣＵのファームウェアを不正に書き換えられてしまうリスクが存在する。
　本発明は、外部ツールに付与された機密情報が漏洩した場合に全てのＥＣＵのファームウェアが不正に書き換えられるリスクを低減して、外部ツールにファームウェア等のＥＣＵ内のデータを更新させるための更新管理方法を提供する。また、本発明は、リスクを低減して外部ツールにＥＣＵ内のデータを更新させるための更新管理装置、及び、この更新管理装置のための制御プログラムを提供する。
　上記課題を解決するために本発明の一態様に係る更新管理方法は、バスを介して通信を行う複数の電子制御ユニットを備え、外部ツールが接続される車載ネットワークシステムにおいて用いられる更新管理方法であって、前記外部ツールの権限を示す更新権限情報を受信して検証し、前記外部ツールから、１つ又は複数の前記電子制御ユニットが保持するデータの更新を指示する更新メッセージが送信された場合において、前記検証が成功し、かつ、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージに対応して前記１つ又は複数の電子制御ユニットにより前記更新を実行し、前記検証が失敗したとき、又は、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記１つ又は複数の電子制御ユニットによる前記更新メッセージに対応した前記更新を抑止する更新管理方法である。
　また、上記課題を解決するために本発明の一態様に係る更新管理装置は、バスを介して通信を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて診断ポートと繋がった１つの電子制御ユニットである更新管理装置であって、前記診断ポートに接続された外部ツールから前記診断ポートを介して送信される、当該外部ツールの権限を示す更新権限情報、及び、１つ又は複数の前記電子制御ユニットが保持するデータの更新を指示する更新メッセージを、受信する受信部と、前記受信部により受信された前記更新権限情報を検証する検証部と、前記受信部により前記更新メッセージが受信された場合において、前記検証部による前記検証が成功し、かつ、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージを前記バスに転送し、前記検証部による前記検証が失敗したとき、又は、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記転送を抑止する転送部とを備える更新管理装置である。
　また、上記課題を解決するために本発明の一態様に係る制御プログラムは、バスを介して通信を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて診断ポートと繋がった１つの電子制御ユニットとしての、プロセッサを有する更新管理装置に、所定の更新管理処理を実行させるための制御プログラムであって、前記更新管理処理は、前記診断ポートに接続された外部ツールから前記診断ポートを介して送信される、当該外部ツールの権限を示す更新権限情報を受信する更新権限情報受信ステップと、前記更新権限情報受信ステップにおいて受信された前記更新権限情報を検証する検証ステップと、前記外部ツールから前記診断ポートを介して送信される、１つ又は複数の前記電子制御ユニットが保持するデータの更新を指示する更新メッセージを受信する更新メッセージ受信ステップと、前記更新メッセージ受信ステップで前記更新メッセージが受信された場合において、前記検証ステップでの前記検証が成功し、かつ、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージを前記バスに転送し、前記検証ステップでの前記検証が失敗したとき、又は、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記転送を抑止する転送制御ステップとを含む制御プログラムである。
　本発明によれば、外部ツールに付与された機密情報が漏洩した場合に全てのＥＣＵのファームウェアが不正に書き換えられるリスクを低減して、外部ツールにＥＣＵ内のデータを更新させ得る。
実施の形態１に係る車載ネットワークシステムの全体構成図である。 ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。 ＥＣＵ及び外部ツールに関わる鍵発行システムを示す図である。 公開鍵証明書の構成を示す図である。 公開鍵証明書に記載された更新権限情報のレベルとＥＣＵの機能種別との対応関係を示す図である。 ＥＣＵが保持する共有鍵を示す図である。 実施の形態１に係るマスタＥＣＵ（更新管理装置）の構成図である。 実施の形態１に係るレベル情報を示す図である。 ＥＣＵの構成図である。 受信ＩＤリストを示す図である。 実施の形態１に係る共有鍵更新シーケンスを示す図である（図１２に続く）。 実施の形態１に係る共有鍵更新シーケンスを示す図である（図１１から続く）。 実施の形態２に係る車載ネットワークシステムの全体構成図である。 実施の形態２に係るレベル情報を示す図である。 実施の形態２に係る共有鍵更新シーケンスを示す図である（図１６に続く）。 実施の形態２に係る共有鍵更新シーケンスを示す図である（図１５から続く）。 実施の形態３に係るマスタＥＣＵ（更新管理装置）の構成図である。 実施の形態３に係る共有鍵と有効期限等とを対応付けた情報を示す図である。 実施の形態３に係る共有鍵の更新を促す画面の一例を示す図である。 実施の形態４に係る共有鍵更新シーケンスを示す図である（図２１に続く）。 実施の形態４に係る共有鍵更新シーケンスを示す図である（図２０から続く）。 実施の形態４に係るサーバが保持するログ情報を示す図である。
　本発明の一態様に係る更新管理方法は、バスを介して通信を行う複数の電子制御ユニットを備え、外部ツールが接続される車載ネットワークシステムにおいて用いられる更新管理方法であって、前記外部ツールの権限を示す更新権限情報を受信して検証し、前記外部ツールから、１つ又は複数の前記電子制御ユニットが保持するデータの更新を指示する更新メッセージが送信された場合において、前記検証が成功し、かつ、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージに対応して前記１つ又は複数の電子制御ユニットにより前記更新を実行し、前記検証が失敗したとき、又は、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記１つ又は複数の電子制御ユニットによる前記更新メッセージに対応した前記更新を抑止する更新管理方法である。これにより、検証可能な更新権限情報により外部ツール毎に、ＥＣＵ内のデータの更新を指示する更新メッセージを送信する権限を異なるように定め得る。そして、車載ネットワークシステムにおける一部のＥＣＵ内のデータの更新メッセージについて送信する権限を有している外部ツールだけがその一部のＥＣＵ内のデータを更新させ得る。また、その一部のＥＣＵ内のデータの更新メッセージについての送信の権限を有している外部ツールについて機密情報が漏洩しても、その一部のＥＣＵ以外のＥＣＵについては不正に書き換えられない。このため、車載ネットワークの全てのＥＣＵのファームウェア等が不正に書き換えられるリスクを低減して、外部ツールにＥＣＵ内のデータを更新させ得る。
　また、前記複数の電子制御ユニットは、Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ（ＣＡＮ）プロトコルに従って前記バスを介して通信を行い、前記外部ツールは、ＣＡＮプロトコルに従って前記更新メッセージを送信することとしても良い。これにより、ＣＡＮに従った車載ネットワークシステムにおいて適切に権限を有する外部ツールにＥＣＵ内のデータを更新させ得る。
　また、前記外部ツールから前記更新メッセージが送信された場合において、当該更新メッセージのメッセージＩＤに基づいて、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示すか否かを判定し、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示すと判定したときには、前記メッセージＩＤを有する前記更新メッセージを受信するように定められている前記電子制御ユニットにより前記更新を実行することとしても良い。これにより、ＣＡＮのフレームのＩＤ（メッセージＩＤ）により更新メッセージでの更新指示の対象となるＥＣＵか否かの区別がなされる。このため、特定の１又は複数のＥＣＵに対しての更新の権限を、他の１又は複数のＥＣＵに対しての更新の権限と区別でき、例えば更新指示の対象となるＥＣＵに応じた権限を有する適切な外部ツールに限ってその更新を許可することが可能になる。
　また、前記更新権限情報は、前記電子制御ユニットの分類用の複数の機能種別のうち１つ又は複数の機能種別を特定し、特定した当該１つ又は複数の機能種別のいずれかに分類される前記電子制御ユニットに前記更新を行わせる権限を前記外部ツールが有することを表し、前記外部ツールから前記更新メッセージが送信された場合において、当該更新メッセージのメッセージＩＤに基づいて、当該メッセージＩＤを受信するように定められている前記電子制御ユニットの機能種別が、前記更新権限情報により特定される１つ又は複数の機能種別のいずれかと一致するか否かを判別することにより、前記判定を行うこととしても良い。これにより、ＥＣＵを機能面で分類する機能種別毎に、更新の権限を区別して外部ツールに認定するような運用が可能となる。この認定は、例えば検証可能な更新権限情報の付与により行われる。
　また、前記更新権限情報は、１つ又は複数の前記機能種別を特定するための複数のレベルのうち１つのレベルを示し、相対的に高いレベルは、相対的に低いレベルが特定する１つ又は複数の機能種別を包含した複数の機能種別を特定することとしても良い。これにより、外部ツール毎に更新の権限のレベルを異ならせることが可能となる。例えば、低いレベルの権限を有する外部ツールについての機密情報が漏洩してもそのレベルに対応して更新可能なＥＣＵの機能種別以外のＥＣＵ（つまり高いレベルの権限を有する外部ツールによって更新可能なＥＣＵ）については不正に書き換えられない。
　また、１つの前記電子制御ユニットである更新管理装置が、当該更新管理装置と繋がった診断ポートに接続された前記外部ツールから前記更新権限情報を受信して前記検証を行い、前記外部ツールから前記更新メッセージが送信された場合に当該更新メッセージを受信し、当該受信した場合において、前記検証が成功し、かつ、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージを前記バスに転送し、前記検証が失敗したとき、又は、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記転送を抑止することとしても良い。これにより、更新管理装置（マスタＥＣＵ）が更新メッセージを他のＥＣＵへ転送するか否かを制御するので、他のＥＣＵは外部ツールの権限に係る検査を省略し得る。
　また、前記更新メッセージにセッション鍵を用いた所定暗号処理が施されていなければ当該更新メッセージに対応した前記電子制御ユニットによる前記更新を抑止し、前記更新管理装置は、前記更新権限情報の前記受信を、当該更新権限情報を記載した、前記外部ツールの公開鍵に係る公開鍵証明書の受信により行い、前記検証に成功した場合に、前記外部ツールが前記更新メッセージの送信に際して当該更新メッセージに対して所定暗号処理を施すために用いる前記セッション鍵を、前記外部ツールの公開鍵で暗号化して前記外部ツールに送信することとしても良い。これにより、外部ツールの更新の権限について公開鍵証明書を発行することで認定できる。また、公開鍵証明書における公開鍵を利用して外部ツールによる通信内容に係るセキュリティの確保を図ることが可能になる。
　また、前記更新管理装置は、前記外部ツールから前記更新メッセージが送信された場合において、前記車載ネットワークシステムを搭載する車両の状態が所定状態でないときには、前記更新メッセージの前記バスへの転送を抑止することとしても良い。これにより、所定状態として例えば停車状態、エンジンを停止した状態等を定めておくと、例えば走行に関連するＥＣＵの負荷が低下しバストラフィックが比較的少なくなる停車状態等においてＥＣＵ内のデータを更新できるので、例えば更新に不具合が生じる可能性等を低減し得る。
　また、前記更新管理装置は、前記外部ツールから前記更新メッセージが送信された場合において、前記車載ネットワークシステムにおける各電子制御ユニットに電力を供給する電池が所定電池残量を有さないときには、前記更新メッセージの前記バスへの転送を抑止することとしても良い。これにより、所定電池残量として例えば電池の残量が更新に足りる程度に十分な量を定めておくと、更新中の電池切れによる不具合を防ぐことが可能となる。
　また、前記更新管理装置以外の電子制御ユニットと前記更新管理装置とは、通信内容に係る暗号処理用のセッション鍵の伝達に用いるために相互間で共有する共有鍵を保持し、前記更新メッセージが指示する、前記電子制御ユニットが保持するデータの前記更新は、前記共有鍵の更新であることとしても良い。これにより、外部ツールによりマスタＥＣＵとそれ以外のＥＣＵとの間で共有する共有鍵を更新できるようになる。
　また、前記共有鍵の有効期限の一定期間前に前記共有鍵の更新を促す警告情報を出力することとしても良い。これにより、共有鍵の有効期限が切れる前に、鍵更新を促すことができ、共有鍵が有効期限を過ぎて利用し続けられるリスクを低減し得る。
　また、前記更新管理装置は、前記車載ネットワークシステムを、複数の車載ネットワークシステムの中で識別する識別情報と前記更新メッセージの処理結果を示す結果情報とを前記外部ツールに送信することとしても良い。これにより、外部ツール側で車両毎（つまり車載ネットワークシステム毎）におけるＥＣＵ内のデータの更新結果を管理することが可能となる。
　また、前記外部ツールは、前記結果情報と前記識別情報とをサーバに送信することとしても良い。これにより、サーバにおいて車両毎におけるＥＣＵ内のデータの更新結果を管理することが可能となる。
　また、前記更新メッセージが指示する、前記電子制御ユニットが保持するデータの前記更新は、前記電子制御ユニットのファームウェアの更新であることとしても良い。これにより、ＥＣＵのファームウェアの更新についての権限を外部ツール毎に柔軟に設定できるようになる。
　また、本発明の一態様に係る更新管理装置は、バスを介して通信を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて診断ポートと繋がった１つの電子制御ユニットである更新管理装置であって、前記診断ポートに接続された外部ツールから前記診断ポートを介して送信される、当該外部ツールの権限を示す更新権限情報、及び、１つ又は複数の前記電子制御ユニットが保持するデータの更新を指示する更新メッセージを、受信する受信部と、前記受信部により受信された前記更新権限情報を検証する検証部と、前記受信部により前記更新メッセージが受信された場合において、前記検証部による前記検証が成功し、かつ、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージを前記バスに転送し、前記検証部による前記検証が失敗したとき、又は、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記転送を抑止する転送部とを備える更新管理装置である。これにより、外部ツールに付与された機密情報が漏洩した場合に全てのＥＣＵ内のファームウェア等が不正に書き換えられるリスクを低減して、外部ツールにＥＣＵ内のデータを更新させることが可能になる。
　また、本発明の一態様に係る制御プログラムは、バスを介して通信を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて診断ポートと繋がった１つの電子制御ユニットとしての、プロセッサを有する更新管理装置に、所定の更新管理処理を実行させるための制御プログラムであって、前記更新管理処理は、前記診断ポートに接続された外部ツールから前記診断ポートを介して送信される、当該外部ツールの権限を示す更新権限情報を受信する更新権限情報受信ステップと、前記更新権限情報受信ステップにおいて受信された前記更新権限情報を検証する検証ステップと、前記外部ツールから前記診断ポートを介して送信される、１つ又は複数の前記電子制御ユニットが保持するデータの更新を指示する更新メッセージを受信する更新メッセージ受信ステップと、前記更新メッセージ受信ステップで前記更新メッセージが受信された場合において、前記検証ステップでの前記検証が成功し、かつ、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージを前記バスに転送し、前記検証ステップでの前記検証が失敗したとき、又は、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記転送を抑止する転送制御ステップとを含む制御プログラムである。このプログラムを更新管理装置にインストールして、プロセッサに実行させることにより、外部ツールに付与された機密情報が漏洩した場合に全てのＥＣＵ内のファームウェア等が不正に書き換えられるリスクを低減して、外部ツールにＥＣＵ内のデータを更新させることが可能になる。
　なお、これらの全般的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータで読み取り可能なＣＤ－ＲＯＭ等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されても良い。
　以下、実施の形態に係る更新管理方法を用いる車載ネットワークシステムについて、図面を参照しながら説明する。ここで示す実施の形態は、いずれも本発明の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、ステップ（工程）及びステップの順序等は、一例であって本発明を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
　（実施の形態１）
　以下、本発明の実施の形態として、更新管理装置としてのマスタＥＣＵ１００を含む複数のＥＣＵがバスを介して通信する車載ネットワークシステム１０において用いられる更新管理方法について、図面を用いて説明する。
　更新管理方法として、本実施の形態では、車載ネットワークシステム１０の診断ポートに外部ツールが接続された場合においてマスタＥＣＵ１００が、外部ツール３０を認証して、一定条件を満たすときに限って外部ツール３０にＥＣＵのデータ（ファームウェア等）の更新を許可する例を示す。
　［１．１　車載ネットワークシステム１０の全体構成］
　図１は、実施の形態１に係る車載ネットワークシステム１０の全体構成を示す図である。なお、同図には車載ネットワークシステム１０の他に、外部ツール３０が示されている。この外部ツール３０は、例えば各種ＥＣＵの製造、メンテナンスを行う事業者等により製造された、個々の各種外部ツール（例えば後述する外部ツール３０ａ、３０ｂ）を代表して表したものである。車載ネットワークシステム１０は、ＣＡＮプロトコルに従って通信するネットワーク通信システムの一例であり、制御装置、センサ等の各種機器が搭載された自動車（車両）におけるネットワーク通信システムである。車載ネットワークシステム１０は、ＣＡＮプロトコルに従ってバスを介してフレームに係る通信を行う複数の装置（ノード）を備え、更新管理方法を用いる。具体的には図１に示すように車載ネットワークシステム１０は、診断ポート６００と、バス５００ａ～５００ｄと、マスタＥＣＵ（更新管理装置）１００、ヘッドユニット２００、ゲートウェイ３００、各種機器に接続されたＥＣＵ４００ａ～４００ｆ等のＥＣＵといったバスに接続された各ノードとを含んで構成される。なお、車載ネットワークシステム１０には、マスタＥＣＵ１００及びＥＣＵ４００ａ～４００ｆ以外にもいくつものＥＣＵが含まれ得るが、ここでは、便宜上マスタＥＣＵ１００及びＥＣＵ４００ａ～４００ｆに注目して説明を行う。ＥＣＵは、例えば、プロセッサ（マイクロプロセッサ）、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置である。メモリは、ＲＯＭ、ＲＡＭ等であり、プロセッサにより実行される制御プログラム（コンピュータプログラム）を記憶することができる。例えばプロセッサが、制御プログラムに従って動作することにより、ＥＣＵは各種機能を実現することになる。なお、コンピュータプログラムは、所定の機能を達成するために、プロセッサに対する指令を示す命令コードが複数個組み合わされて構成されたものである。
　診断ポート６００は、車載ネットワークシステム１０を構成するＥＣＵのメンテナンスを行う際に外部ツール３０を接続するポートであり、マスタＥＣＵ１００とバス５００ｄで繋がっている。診断ポート６００は、例えばＯＢＤ２に準拠したコネクタである。外部ツール３０は、診断ポート６００と接続することにより、車載ネットワークシステム１０へとＣＡＮプロトコルに従ったフレームを送信できる。例えば、外部ツール３０は、ＥＣＵのファームウェア等を更新するための更新メッセージ或いはＥＣＵの故障診断のための診断用のメッセージ等、車載ネットワークシステム１０において予め定められた一定範囲のメッセージＩＤを含むメッセージを送信し得る。ここでは、特に、ＥＣＵのファームウェア及び共有鍵のそれぞれを更新するために予め定められている一定範囲のメッセージＩＤを含む更新メッセージ（つまり更新要求用のフレーム）を外部ツールが送信することに注目して説明する。
　マスタＥＣＵ１００は、外部ツール３０の認証を行い、外部ツール３０の証明書（後述する公開鍵証明書）に記載された更新権限情報に基づいて、外部ツールからの更新メッセージに対して更新を許可するか否かに係る判定等を行う役割を有する更新管理装置としての一種のＥＣＵである。また、マスタＥＣＵ１００は、車載ネットワークシステム１０における複数のＥＣＵのうち自装置以外の１以上のＥＣＵそれぞれとの相互間で、フレームでの通信内容に係る暗号処理用のセッション鍵の伝達に用いるための、事前に共有した同一の共有鍵を保持し、セッション鍵を各ＥＣＵに伝達する機能を有する。
　ＥＣＵ４００ａ～４００ｆは、バス５００ａ～５００ｃのいずれかと接続され、それぞれエンジン３１０、ブレーキ３２０、ドア開閉センサ３３０、窓開閉センサ３４０、エアバッグ３５０、ヘッドユニット２００に接続されている。ＥＣＵ４００ａ～４００ｅのそれぞれは、接続されている機器（エンジン３１０等）の状態を取得し、定期的に状態を表すフレームをネットワーク（つまりバス）に送信している。ヘッドユニット２００は、例えば、自動車のインストルメントパネル（インパネ）等に設けられた液晶ディスプレイ（ＬＣＤ：Liquid Crystal Display）等の表示装置を含み、車両の運転者への報知を行い得る。ヘッドユニット２００に接続されたＥＣＵ４００ｆは、バス５００ｃからフレームを受信して、フレームが表す各種状態を、ヘッドユニット２００の表示装置に表示させる機能を有する。
　ゲートウェイ３００は、ＥＣＵ４００ａ及びＥＣＵ４００ｂと繋がるバス５００ａと、マスタＥＣＵ１００及びＥＣＵ４００ｃ～４００ｅと繋がるバス５００ｂと、ＥＣＵ４００ｆと繋がるバス５００ｃとに接続しており、それぞれのバスから受信したフレームを他のバスに転送する機能を有する。また受信したフレームを転送するかしないかを接続されたバス間毎に切り替えることも可能である。ゲートウェイ３００は一種のＥＣＵである。
　車載ネットワークシステム１０においてはＣＡＮプロトコルに従って、マスタＥＣＵ４００を含む各ＥＣＵがバスを介してフレームの授受を行う。ＣＡＮプロトコルにおけるフレームには、データフレーム、リモートフレーム、オーバーロードフレーム及びエラーフレームがあるが、説明の便宜上、ここではデータフレームを中心に説明する。
　［１．２　データフレームフォーマット］
　以下、ＣＡＮプロトコルに従ったネットワークで用いられるフレームの１つであるデータフレームについて説明する。
　図２は、ＣＡＮプロトコルで規定されるデータフレームのフォーマットを示す図である。同図には、ＣＡＮプロトコルで規定される標準ＩＤフォーマットにおけるデータフレームを示している。データフレームは、ＳＯＦ（Start Of Frame）、ＩＤフィールド、ＲＴＲ（Remote Transmission Request）、ＩＤＥ（Identifier Extension）、予約ビット「ｒ」、ＤＬＣ（Data Length Code）、データフィールド、ＣＲＣ（Cyclic Redundancy Check）シーケンス、ＣＲＣデリミタ「ＤＥＬ」、ＡＣＫ（Acknowledgement）スロット、ＡＣＫデリミタ「ＤＥＬ」、及び、ＥＯＦ（End Of Frame）の各フィールドで構成される。
　ＳＯＦは、１ｂｉｔのドミナントで構成される。バスがアイドルの状態はレセシブになっており、ＳＯＦによりドミナントへ変更することでフレームの送信開始を通知する。
　ＩＤフィールドは、１１ｂｉｔで構成される、データの種類を示す値であるＩＤ（つまりメッセージＩＤ）を格納するフィールドである。複数のノードが同時に送信を開始した場合、このＩＤフィールドで通信調停を行うために、ＩＤが小さい値を持つフレームが高い優先度となるよう設計されている。
　ＲＴＲは、データフレームとリモートフレームとを識別するための値であり、データフレームにおいてはドミナント１ｂｉｔで構成される。
　ＩＤＥと「ｒ」とは、両方ドミナント１ｂｉｔで構成される。
　ＤＬＣは、４ｂｉｔで構成され、データフィールドの長さを示す値である。なお、ＩＤＥ、「ｒ」及びＤＬＣを合わせてコントロールフィールドと称する。
　データフィールドは、最大６４ｂｉｔで構成される送信するデータの内容を示す値である。８ｂｉｔ毎に長さを調整できる。送られるデータの仕様については、ＣＡＮプロトコルで規定されておらず、車載ネットワークシステム１０において定められる。従って、車種、製造者（メーカ）等に依存した仕様となる。
　ＣＲＣシーケンスは、１５ｂｉｔで構成される。ＳＯＦ、ＩＤフィールド、コントロールフィールド及びデータフィールドの送信値より算出される。
　ＣＲＣデリミタは、１ｂｉｔのレセシブで構成されるＣＲＣシーケンスの終了を表す区切り記号である。なお、ＣＲＣシーケンス及びＣＲＣデリミタを合わせてＣＲＣフィールドと称する。
　ＡＣＫスロットは、１ｂｉｔで構成される。送信ノードはＡＣＫスロットをレセシブにして送信を行う。受信ノードはＣＲＣシーケンスまで正常に受信ができていればＡＣＫスロットをドミナントとして送信する。レセシブよりドミナントが優先されるため、送信後にＡＣＫスロットがドミナントであれば、送信ノードは、いずれかの受信ノードが受信に成功していることを確認できる。
　ＡＣＫデリミタは、１ｂｉｔのレセシブで構成されるＡＣＫの終了を表す区切り記号である。
　ＥＯＦは、７ｂｉｔのレセシブで構成されており、データフレームの終了を示す。
　［１．３　鍵発行システム］
　図３は、上述したＥＣＵ及び外部ツールに関わる鍵発行システムを示す図である。鍵発行機関２０は、公開鍵証明書４０ａ～４０ｃ、秘密鍵５０ａ～５０ｃ、共有鍵６０をメーカ２１に配布する。配布された鍵や証明書は、メーカ２１によって製造段階等において、外部ツール３０ａ、３０ｂ、マスタＥＣＵ１００、ＥＣＵ４００ａ～４００ｆに書き込まれる。メーカ２１は、例えばＯＥＭメーカ（Original Equipment Manufacturer）、ＥＣＵベンダー等である。公開鍵を記載した公開鍵証明書と、秘密鍵とは、公開鍵基盤（ＰＫＩ：Public Key Infrastructure）で利用され、公開鍵及び秘密鍵が、楕円暗号、ＲＳＡ暗号等の鍵ペアである。この秘密鍵及び公開鍵証明書は、マスタＥＣＵ１００と外部ツール３０ａ～ｂ間の認証に用いられる。共有鍵６０は、個々の共有鍵を代表的に表している。この共有鍵６０は、共通鍵暗号方式のＡＥＳ（Advanced Encryption Standard）の鍵であり、マスタＥＣＵ１００と他の各ＥＣＵとの間で共有され、フレームに係る暗号処理用のセッション鍵の伝達に用いられる。フレームに係る暗号処理としては、フレームのデータフィールドの内容の暗号化及び復号の他に、例えば、フレームの送信側で、フレームのデータフィールドに、メッセージ認証コード（ＭＡＣ：Message Authentication Code）を生成して付加して送信し、受信側ではそのＭＡＣについて検証する処理が挙げられる。このＭＡＣによりデータの改ざんの検出が可能となる。セッション鍵は、例えばＭＡＣの生成に用いられる。
　図３の例では、外部ツール３０ａには、公開鍵証明書４０ａと秘密鍵５０ａとが書き込まれ、外部ツール３０ｂには、公開鍵証明書４０ｂと秘密鍵５０ｂとが書き込まれ、マスタＥＣＵ２０には公開鍵証明書４０ｃと秘密鍵５０ｃと共有鍵６０とが書き込まれ、ＥＣＵ４００ａ～４００ｆには、共有鍵６０が書き込まれることを示している。図３の例では、公開鍵証明書４０ａに記載された更新権限情報のレベルは３であり、公開鍵証明書４０ｂに記載された更新権限情報のレベルは４である。
　［１．４　公開鍵証明書］
　図４は、鍵発行機関２０が、外部ツール３０ａ、３０ｂに書き込まれるために発行つまり配布する公開鍵証明書４０ａの構成の一例を示す図である。公開鍵証明書４０ｂも同様の構成を有する。
　同図に示すように、公開鍵証明書は、バージョン、発行者、有効期間の開始と終了、証明書識別情報（ＩＤ）、公開鍵、更新権限情報（レベル）、及びこれらに対する署名を含んで構成される。署名は、鍵発行機関２０或いはポータルサーバ等の認証局により付与される。このため、マスタＥＣＵ１００は外部ツール３０の認証を、外部ツール３０から公開鍵証明書を取得して署名の検証等により、行うことができる。
　公開鍵証明書中の更新権限情報は、外部ツール３０（外部ツール３０ａ、３０ｂ等）に対して、どの種別のＥＣＵについてのＥＣＵ内のデータの更新を指示する更新メッセージを送信する権限が認められているかについて示す情報であり、具体的には、権限について複数段階に区分されたレベルのうち１つを示す。このため、外部ツール３０について署名主体である認証局等により認定された権限のレベルが更新権限情報に示されていることになる。
　なお、マスタＥＣＵ１００に書き込まれる公開鍵証明書４０ｃは、図４に示す構成例のうち更新権限情報以外の各要素を含む。
　［１．５　更新権限情報］
　図５は、図３の公開鍵証明書に記載された更新権限情報の内容としてのレベル（つまり権限のレベル）と、ＥＣＵの機能の分類用の複数の機能種別との対応関係の一例を示す図である。
　まず、ＥＣＵの機能種別について説明する。駆動系機能は、エンジン、モータ、燃料、電池、トランスミッション等の制御といった車両の走行に関連する機能である。駆動系機能の機能種別には、例えば、エンジン３１０に関わるＥＣＵ４００ａが該当する。シャーシ系機能は、ブレーキ、ステアリング等の「曲がる」、「止まる」等といった車両の挙動等の制御に関連する機能である。シャーシ系機能の機能種別には、例えば、ブレーキ３２０に関わるＥＣＵ４００ｂが該当する。ボディ系機能は、ドアロック、エアコン、ライト、ウィンカー等といった車両の装備の制御に関連する機能である。ボディ系機能の機能種別には、例えば、ドア開閉センサ３３０に関わるＥＣＵ４００ｃ及び窓開閉センサ３４０に関わるＥＣＵ４００ｄが該当する。また、安全快適機能は、自動ブレーキ、車線維持機能、車間距離維持機能、衝突防止機能、エアバッグ等といった自動的に安全で快適な運転を実現するための機能である。安全快適機能の機能種別には、エアバッグ３５０に関わるＥＣＵ４００ｅが該当する。ＩＴＳ（Intelligent Transport Systems）系機能は、ＥＴＣ（Electronic Toll Collection System）等の高度道路交通システムに対応した機能である。テレマティクス系機能は、移動体通信を用いたサービスに対応する機能である。インフォテインメント系機能は、カーナビゲーション、オーディオ等に関連したエンターテインメント機能である。インフォテインメント系機能の機能種別には、例えば、ヘッドユニット２００に関わるＥＣＵ４００ｆが該当する。
　公開鍵証明書の署名主体である認証局等に認定された、更新権限情報の内容としての権限のレベルは、図５に例示する対応関係等に基づき、上述した複数の機能種別のうち１つ又は複数の機能種別を特定する。そして、その公開鍵証明書を付与された外部ツールは、更新権限情報のレベルにより特定されるその１つ又は複数の機能種別のいずれかに分類されるＥＣＵにそのＥＣＵ内のデータ（ファームウェア、共有鍵）の更新を行わせる権限を、つまりファームウェア或いは共有鍵の更新用の更新メッセージを送信する権限を、有すると認定されていることになる。
　図５の例によれば、更新権限について最も高いレベル４から最も低いレベル１の４段階のいずれかのレベルを示す更新権限情報を記載した公開鍵証明書が、個々の外部ツールに付与される（つまり書き込まれる）ことになる。個々の外部ツールは、機能、構成等がそれぞれ相違し得る。このため、例えば、外部ツールが取り扱う対象となるＥＣＵの機能種別、外部ツールの機密性、信頼性、その外部ツールを製造する事業者の信頼性その他の各種事情を勘案して個々の外部ツールに対する更新権限情報を定め得る。なお、図５は、レベルの一例を示すに過ぎず、この例と異なるように、レベルの段階数、レベルと機能種別との対応関係等を定めても良い。また、ある複数のレベル（例えばレベル４及びレベル２）のそれぞれが同じ１つの機能種別と対応するような対応関係を定めても良い。また、機能種別の分類についても図５の例と異なるように定め得る。ここでは、更新権限情報において相対的に高いレベルは、それより低いレベルが特定する１つ又は複数の機能種別を包含した複数の機能種別を特定するもの、つまり高いレベルは低いレベルの権限を包含するものとして説明する。しかし、権限のレベル間において権限の包含関係がないように、レベルと機能種別との対応関係を定めても良い。但し、外部ツールに対して認定された権限のレベルが相対的に低い場合において、車両の走行、挙動等に関連しない一部のＥＣＵ内のデータの更新だけを許可してその一部以外のＥＣＵ内のデータの更新をさせないことは有用である。具体的には、外部ツールについて認められた権限のレベル（つまり更新権限情報の内容であるレベル）が３であれば、その外部ツールは、レベル３以下の全てのレベル（つまりレベル１～レベル３）それぞれに対応する機能種別に分類される各ＥＣＵに対して更新メッセージを送信してＥＣＵ内のデータの更新を実行させることが許可される。
　なお、車載ネットワークシステム１０においてマスタＥＣＵ１００は、外部ツール３０が診断ポート６００に接続された場合に、権限のレベルを定める更新権限情報を外部ツール３０から受信しこの更新権限情報に基づいて、外部ツール３０が送信する更新メッセージに対して、更新を許可するか否かに係る判定を行う。マスタＥＣＵ１００は、この判定において、上述したレベルと機能種別との対応関係（図５参照）に基づいて定められたレベル情報１０４０を参照する。レベル情報１０４０については、図８を用いて後に説明する。
　［１．６　共有鍵］
　図６は、マスタＥＣＵ１００、ＥＣＵ４００ａ～４００ｆが保持する共有鍵を示す図である。上述した共有鍵６０は、具体的には同図に示すように、全ＥＣＵで共有される共有鍵６０ａと、ＥＣＵ４００ｆとマスタＥＣＵ１００とで共有される共有鍵６０ｂと、ＥＣＵ４００ｃ、４００ｄとマスタＥＣＵ１００とで共有される共有鍵６０ｃと、ＥＣＵ４００ａ、４００ｂとマスタＥＣＵ１００とで共有される共有鍵６０ｄと、ＥＣＵ４００ｅとマスタＥＣＵ１００とで共有される共有鍵６０ｅがある。
　［１．７　マスタＥＣＵ（更新管理装置）１００の構成］
　図７は、マスタＥＣＵ１００の構成図である。マスタＥＣＵ１００は、送受信部１０１と、鍵保持部１０２と、判定部１０３と、レベル情報保持部１０４と、フレーム送受信部１６０と、フレーム解釈部１５０と、受信ＩＤ判断部１３０と、受信ＩＤリスト保持部１４０と、フレーム処理部１１０と、フレーム生成部１２０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、マスタＥＣＵ１００における通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。
　送受信部１０１は、マスタＥＣＵ１００と外部ツール３０（外部ツール３０ａ、３０ｂ）との認証のためにマスタＥＣＵ１００の公開鍵証明書４０ｃの送信及び外部ツール３０からの公開鍵証明書（公開鍵証明書４０ａ或いは公開鍵証明書４０ｂ）を受信する。また、送受信部１０１は、外部ツール３０から診断ポート６００を介してバス５００ｄに対して送信されるＣＡＮプロトコルに従った更新メッセージを受信し、また、更新メッセージによる更新の結果の送信を行う。
　鍵保持部１０２は、マスタＥＣＵ１００の公開鍵証明書４０ｃ、秘密鍵５０ｃ、共有鍵６０ａ～６０ｅを保持する。なお、ＣＡＮプロトコルに従ったデータフレームにおけるデータへの暗号処理としてＭＡＣを付与する場合に用いるＭＡＣ鍵を鍵保持部１０２に保持しても良い。また、外部ツール３０等との間での通信に係る暗号処理に用いるセッション鍵を鍵保持部１０２に保持しても良い。セッション鍵はＭＡＣの生成にも利用され得る。
　フレーム送受信部１６０は、バス５００ｂに対して、ＣＡＮプロトコルに従ったフレームを送受信する。つまり、ＥＣＵ４００ａ～４００ｆからのフレームを受信し、ＥＣＵ４００ａ～４００ｆへフレームを送信する。バス５００ｂからフレームを１ｂｉｔずつ受信し、フレーム解釈部１５０に伝達する。また、フレーム生成部１２０より通知を受けたフレームの内容をバス５００ｂに１ビットずつ送信する。
　フレーム解釈部１５０は、フレーム送受信部１６０よりフレームの値を受け取り、ＣＡＮプロトコルで規定されているフレームフォーマットにおける各フィールドにマッピングするよう解釈を行う。フレーム解釈部１５０は、ＩＤフィールドと判断した値（メッセージＩＤ）を受信ＩＤ判断部１３０へ転送する。受信ＩＤ判断部１３０から通知される判定結果に応じて、ＩＤフィールドの値と、ＩＤフィールド以降に現れるデータフィールドとを、フレーム処理部１１０へ転送するか、フレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するように、フレーム生成部１２０へ通知する。また、フレーム解釈部１５０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
　受信ＩＤ判断部１３０は、フレーム解釈部１５０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部１４０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部１３０は、フレーム解釈部１５０へ通知する。また、受信ＩＤ判断部１３０は、フレーム解釈部１５０と同様に、判定部１０３に対しても、メッセージＩＤが受信すべきフレームのものであるかどうかの判定を行って判定結果を通知する。
　受信ＩＤリスト保持部１４０は、マスタＥＣＵ１００が受信するメッセージＩＤのリストである受信ＩＤリストを保持する。
　フレーム生成部１２０は、フレーム解釈部１５０から通知されたエラーフレーム送信の要求に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部１６０へ通知して送信させる。また、判定部１０３よりフレームの生成の指示を受けると、データへの暗号処理（例えばセッション鍵等に対応したＭＡＣの付加等）を施してフレームを構成し、フレーム送受信部１６０へ通知して送信させる。
　判定部１０３は、外部ツール３０から受信した、更新権限情報を含む公開鍵証明書を検証することで、外部ツール３０を認証する。判定部１０３が外部ツール３０から受信した公開鍵証明書の検証に成功すると外部ツール３０の認証に成功したことになる。なお、判定部１０３が公開鍵証明書の検証に成功したことは更新権限情報の検証に成功したことでもある。判定部１０３は、送受信部１０１により更新メッセージが受信された場合に、更新権限情報の検証が成功しており、かつ、その更新メッセージの送信が外部ツール３０の権限範囲内であることを更新権限情報が示すか否かを判定することで、更新メッセージに対応した更新を許可するか否かの判定を行う。この判定は、受信した更新メッセージのメッセージＩＤと受信した公開鍵証明書に記載された更新権限情報が示すレベルとが、レベル情報保持部１０４が保持しているレベル情報１０４０（後述）に照らして適切に対応したものであるか否かを判別することにより行われる。判定部１０３は、外部ツール３０によりなされた更新メッセージの送信が外部ツール３０の権限範囲内であることを更新権限情報が示すと判定した場合（つまり許可される更新メッセージであると判定した場合）には、フレーム生成部１２０に、他のＥＣＵへの転送用（つまりバス５００ｂへの送出用）にその（元の）更新メッセージに対応したフレームである新たな更新メッセージを生成するよう指示する。なお、フレーム生成部１２０が転送用に生成する新たな更新メッセージは、元の更新メッセージとメッセージＩＤは同じで更新メッセージのデータフィールド内におけるデータも実質的には同じであり、データに暗号処理を施す場合においてそのデータに施された暗号処理（例えばデータに付加されたＭＡＣ）が異なるものである。フレーム生成部１２０で生成された更新メッセージはフレーム送受信部１６０によりバス５００ｂに送出される。これにより、外部ツール３０からの更新権限情報の検証が成功しており、かつ、外部ツール３０からの更新メッセージが許可される更新メッセージであると判定した場合にはマスタＥＣＵ１００によってその更新メッセージが他のＥＣＵへと（つまりバス５００ｂへと）転送されることになる。また、判定部１０３は、外部ツール３０からの共有鍵の更新用の更新メッセージが許可される更新メッセージであると判定した場合には、鍵保持部１０２に保持されている共有鍵を更新する。
　フレーム処理部１１０は、バス５００ｂから受信したフレームのデータに応じて予め定められた処理を行う。フレーム処理部１１０は、例えば、バス５００ｂから更新メッセージによる各ＥＣＵでの更新の結果を示すフレームを受信した場合には、その更新の結果を内容とするメッセージ（フレーム）を生成して送受信部１０１に診断ポート６００へ繋がるバス５００ｄへと送出させる。
　レベル情報保持部１０４は、レベル情報１０４０を保持する。
　［１．８　レベル情報］
　図８は、レベル情報保持部１０４が保持するレベル情報１０４０の一例を示す図である。
　レベル情報１０４０は、メッセージＩＤ１０４１とレベル１０４２とを対応付けた情報であり、判定部１０３において外部ツール３０からの更新メッセージを許可するか否かの判定に用いられる。
　メッセージＩＤ１０４１は、外部ツール３０から送信され得る更新メッセージのメッセージＩＤを示す。ここでは、ＥＣＵが保持する共有鍵の更新用の更新メッセージについてのメッセージＩＤとして、「０ｘ１００」～「０ｘ１０４」が定められており、ＥＣＵのファームウェアの更新用の更新メッセージについてのメッセージＩＤとして、「０ｘ２００」～「０ｘ２０６」が定められているものとして説明する。
　レベル１０４２は、対応するメッセージＩＤの更新メッセージを送信するために必要な権限のレベルを示す。このレベルは、更新権限情報の内容としてのレベルと呼応している。例えば、外部ツール３０の公開鍵証明書に記載された更新権限情報が示すレベルの値が、レベル１０４２の値と同じかこれより高い権限を示す値を示せば、そのレベル１０４２の値と対応付けられたメッセージＩＤ１０４１の更新メッセージを送信する権限を外部ツール３０が有することになる。逆に、外部ツール３０の公開鍵証明書に記載された更新権限情報が示すレベルの値が、レベル１０４２の値より低い権限を示す値であれば、そのレベル１０４２と対応付けられたメッセージＩＤ１０４１の更新メッセージを送信する権限を外部ツール３０が有さないことになる。
　図８に示すメッセージＩＤ「０ｘ１００」は、マスタＥＣＵ１００及びＥＣＵ４００ａ～４００ｆが保持している共有鍵６０ａの更新用の更新メッセージについてのメッセージＩＤである。レベル情報１０４０において、このメッセージＩＤ「０ｘ１００」に対応するレベル１０４２の値は、最も高い４と設定されている。この４は、共有鍵６０ａの更新の対象となる各ＥＣＵの機能種別に対応するレベルのうち最も高いレベル（具体的にはＥＣＵ４００ｅの機能種別である安全快適機能に対応するレベル）の値である（図５参照）。
　メッセージＩＤ「０ｘ１０１」は、マスタＥＣＵ１００及びＥＣＵ４００ｅが保持している共有鍵６０ｅの更新用の更新メッセージについてのメッセージＩＤである。安全快適機能を有するＥＣＵ４００ｅに対応して、レベル１０４２の値は、４と設定されている。
　メッセージＩＤ「０ｘ１０２」は、マスタＥＣＵ１００及びＥＣＵ４００ａ、４００ｂが保持している共有鍵６０ｄの更新用の更新メッセージについてのメッセージＩＤである。駆動系機能を有するＥＣＵ４００ａ及びシャーシ系機能を有するＥＣＵ４００ｂに対応して、レベル１０４２の値は、３と設定されている。
　メッセージＩＤ「０ｘ１０３」は、マスタＥＣＵ１００及びＥＣＵ４００ｃ、４００ｄが保持している共有鍵６０ｃの更新用の更新メッセージについてのメッセージＩＤである。ボディ系機能を有するＥＣＵ４００ｃ、４００ｄに対応して、レベル１０４２の値は、２と設定されている。
　メッセージＩＤ「０ｘ１０４」は、マスタＥＣＵ１００及びＥＣＵ４００ｆが保持している共有鍵６０ｂの更新用の更新メッセージについてのメッセージＩＤである。インフォテインメント系機能を有するＥＣＵ４００ｆに対応して、レベル１０４２の値は、１と設定されている。
　メッセージＩＤ「０ｘ２００」は、マスタＥＣＵ１００のファームウェアの更新用の更新メッセージについてのメッセージＩＤである。このメッセージＩＤに対応するレベル１０４２の値は、マスタＥＣＵ１００を特別に扱って、最高レベルの４と設定されている。
　メッセージＩＤ「０ｘ２０１」は、ＥＣＵ４００ｅのファームウェアの更新用の更新メッセージについてのメッセージＩＤである。このメッセージＩＤに対応するレベル１０４２の値は、安全快適機能を有するＥＣＵ４００ｅに対応して、４と設定されている。
　メッセージＩＤ「０ｘ２０２」は、ＥＣＵ４００ｂのファームウェアの更新用の更新メッセージについてのメッセージＩＤである。このメッセージＩＤに対応するレベル１０４２の値は、シャーシ系機能を有するＥＣＵ４００ｂに対応して、３と設定されている。
　メッセージＩＤ「０ｘ２０３」は、ＥＣＵ４００ａのファームウェアの更新用の更新メッセージについてのメッセージＩＤである。このメッセージＩＤに対応するレベル１０４２の値は、駆動系機能を有するＥＣＵ４００ａに対応して、３と設定されている。
　メッセージＩＤ「０ｘ２０４」は、ＥＣＵ４００ｃのファームウェアの更新用の更新メッセージについてのメッセージＩＤである。このメッセージＩＤに対応するレベル１０４２の値は、ボディ系機能を有するＥＣＵ４００ｃに対応して、２と設定されている。
　メッセージＩＤ「０ｘ２０５」は、ＥＣＵ４００ｄのファームウェアの更新用の更新メッセージについてのメッセージＩＤである。このメッセージＩＤに対応するレベル１０４２の値は、ボディ系機能を有するＥＣＵ４００ｄに対応して、２と設定されている。
　メッセージＩＤ「０ｘ２０６」は、ＥＣＵ４００ｆのファームウェアの更新用の更新メッセージについてのメッセージＩＤである。このメッセージＩＤに対応するレベル１０４２の値は、インフォテインメント系機能を有するＥＣＵ４００ｆに対応して、１と設定されている。
　［１．９　ＥＣＵ４００ａの構成］
　図９は、ＥＣＵ４００ａの構成図である。ＥＣＵ４００ａは、鍵保持部４０２と、フレーム送受信部４６０と、フレーム解釈部４５０と、受信ＩＤ判断部４３０と、受信ＩＤリスト保持部４４０と、フレーム処理部４１０と、フレーム生成部４２０と、データ取得部４７０とを含んで構成される。これらの各構成要素は、機能的な構成要素であり、その各機能は、ＥＣＵ４００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。なお、ＥＣＵ４００ｂ～４００ｆも、ＥＣＵ４００ａと基本的に同様の構成を備える。
　鍵保持部４０２は、図６に示した共有鍵を保持する。即ちＥＣＵ４００ａの鍵保持部４０２は、共有鍵６０ａ、６０ｄを保持する。ＣＡＮプロトコルに従ったデータフレームにおけるデータへの暗号処理としてＭＡＣを付与する場合に用いるＭＡＣ鍵を鍵保持部４０２に保持しても良い。また、他のＥＣＵ等との間での通信に係る暗号処理に用いるセッション鍵を鍵保持部４０２に保持しても良い。セッション鍵はＭＡＣの生成にも利用され得る。
　フレーム送受信部４６０は、バス５００ａに対して、ＣＡＮのプロトコルに従ったフレームを送受信する。バス５００ａからフレームを１ｂｉｔずつ受信し、フレーム解釈部４５０に転送する。また、フレーム生成部４２０より通知を受けたフレームの内容をバス５００ａに送信する。
　フレーム解釈部４５０は、フレーム送受信部４６０よりフレームの値を受け取り、ＣＡＮプロトコルにおける各フィールドにマッピングするよう解釈を行う。ＩＤフィールドと判断した値は受信ＩＤ判断部４３０へ転送する。受信ＩＤ判断部４３０から通知される判定結果に応じて、ＩＤフィールドの値（メッセージＩＤ）と、ＩＤフィールド以降に現れるデータフィールドとを、フレーム処理部４１０へ転送するか、その判定結果を受けた以降においてフレームの受信を中止する（つまりそのフレームとしての解釈を中止する）かを決定する。また、ＣＡＮプロトコルに則っていないフレームと判断した場合は、エラーフレームを送信するように、フレーム生成部４２０へ通知する。また、フレーム解釈部４５０は、エラーフレームを受信した場合、つまり受け取ったフレームにおける値からエラーフレームになっていると解釈した場合には、それ以降はそのフレームを破棄する、つまりフレームの解釈を中止する。
　受信ＩＤ判断部４３０は、フレーム解釈部４５０から通知されるＩＤフィールドの値を受け取り、受信ＩＤリスト保持部４４０が保持しているメッセージＩＤのリストに従い、そのＩＤフィールド以降のフレームの各フィールドを受信するかどうかの判定を行う。この判定結果を、受信ＩＤ判断部４３０は、フレーム解釈部４５０へ通知する。
　受信ＩＤリスト保持部４４０は、ＥＣＵ４００ａが受信するメッセージＩＤのリストである受信ＩＤリスト（図１０参照）を保持する。
　フレーム処理部４１０は、受信したフレームのデータに応じてＥＣＵ毎に異なる機能に係る処理を行う。例えば、エンジン３１０に接続されたＥＣＵ４００ａは、エンジン３１０の回転速度と他のＥＣＵから受信したフレームのデータが示す車両の一部の状態との関係に応じて、予め定められた制御を行い得る。
　データ取得部４７０は、ＥＣＵに繋がっている機器、センサの状態を示すデータを取得し、フレーム生成部４２０に通知する。
　フレーム生成部４２０は、フレーム解釈部４５０から通知されたエラーフレーム送信の要求に従い、エラーフレームを構成し、エラーフレームをフレーム送受信部４６０へ通知して送信させる。また、フレーム生成部４２０は、データ取得部４７０より通知されたデータに基づいて定めたデータフィールドの値に、予め定められたメッセージＩＤをつけてデータフレームを構成し、フレーム送受信部４６０へ通知して送信させる。なお、フレーム生成部４２０は、データフィールドの値に、ＭＡＣ鍵或いはセッション鍵を用いて生成したＭＡＣを付加し得る。
　［１．１０　受信ＩＤリスト］
　図１０は、ＥＣＵ４００ａの受信ＩＤリスト保持部４４０が保持する受信ＩＤリスト９００の一例を示す。
　図１０の例は、ＥＣＵ４００ａが、メッセージＩＤ「０ｘ１０２」が付された共有鍵の更新用の更新メッセージ、メッセージＩＤ「０ｘ２０３」が付されたファームウェアの更新用の更新メッセージ等を受信することを示している。ＥＣＵ４００ａが受信するメッセージ（フレーム）のメッセージＩＤは、「０ｘ１０２」、「０ｘ２０３」に限られないが、図１０の例では特に更新メッセージのメッセージＩＤに注目して表している。
　なお、マスタＥＣＵ１００の受信ＩＤリスト保持部１４０が保持する受信ＩＤリストも、受信ＩＤリスト９００と同様に、マスタＥＣＵ１００が受信可能なメッセージのメッセージＩＤを列挙した構成である。
　［１．１１　共有鍵更新シーケンス］
　以下、更新管理方法の一例として、外部ツール３０ａを診断ポート６００に接続して、外部ツール３０ａから車載ネットワークシステム１０におけるＥＣＵが保持する共有鍵を更新させる場合の動作（共有鍵更新シーケンス）について、図１１及び図１２を用いて説明する。
　図１１及び図１２は、外部ツール３０ａとマスタＥＣＵ１００とＥＣＵ４００ａとの間で行われる共有鍵更新シーケンスの一例を示す図である。ここでは、便宜上、外部ツール３０の１つとしての外部ツール３０ａ、及び、ＥＣＵ４００ａ～４００ｆのうちの１つであるＥＣＵ４００ａに注目して説明する。また、駆動系機能及びシャーシ系機能を有する各ＥＣＵが保持する共有鍵を更新するために外部ツール３０ａが用いられる場面を想定して説明する。具体的には、駆動系機能を有するＥＣＵ４００ａ及びシャーシ系機能を有するＥＣＵ４００ｂのそれぞれが保持する共有鍵６０ｄの更新のためのメッセージＩＤ「０ｘ１０２」が付された更新メッセージが外部ツール３０ａから車載ネットワークシステム１０へと送信されることになる。ＥＣＵ４００ｂの動作は、ＥＣＵ４００ａの動作と同様であるため、ここでは説明を省略する。
　まず、マスタＥＣＵ１００にバス５００ｄで繋がった診断ポート６００に外部ツール３０ａが物理的に接続された状態で、外部ツール３０ａが、証明書（つまり外部ツール３０ａが保持する公開鍵証明書４０ａ）をバス５００ｄに送出することで、ＥＣＵ１００に対して通信接続のために認証要求を送信する（ステップＳ１００１）。なお、外部ツール３０ａは、例えば、利用者の操作等に応じて車載ネットワークシステム１０のＥＣＵ内のデータ（共有鍵、ファームウェア）の更新用の更新メッセージを送信し得る。但し、更新メッセージによって更新が実現されるためには更新メッセージの送信に先行して、例えば利用者の操作等に応じて、認証要求（証明書）を送信する必要がある。
　マスタＥＣＵ１００の送受信部１０１が公開鍵証明書４０ａを受信して、判定部１０３において、公開鍵証明書４０ａを検証する（ステップＳ１００２）。公開鍵証明書４０ａの検証については、例えば、認証局による署名を検証し、更に、チャレンジレスポンス（ＣＲ）認証方式で公開鍵証明書４０ａに記載された公開鍵と対応する秘密鍵を外部ツール３０ａが保持しているかについて確認する。ＣＲ認証方式では、例えば、マスタＥＣＵ１００は、乱数を外部ツール３０ａに送信し、外部ツール３０ａが乱数を秘密鍵で暗号化した結果である暗号化乱数をマスタＥＣＵ１００に返信すると、マスタＥＣＵは、公開鍵証明書４０ａ内の公開鍵で暗号化乱数を復号し、最初に送信した乱数と等しいかを確認する。ステップＳ１００２における検証に失敗すれば、マスタＥＣＵ１００は、エラー処理を行う（ステップＳ１００３）。ステップＳ１００３でのエラー処理により、外部ツール３０ａからの通信接続が認められなくなり、外部ツール３０ａは例えば更新メッセージを送信してＥＣＵのデータを更新することができなくなる。なお、マスタＥＣＵ１００は、エラー処理として外部ツール３０ａにエラーの旨のレスポンスを返しても良いし、返さなくても良い。
　ステップＳ１００２における検証に成功すれば、マスタＥＣＵ１００は、外部ツール３０ａとの通信において暗号処理を実施するために用いるセッション鍵を、乱数を用いて生成する（ステップＳ１００４）。例えば、更新メッセージ内のデータを暗号化する場合においては、セッション鍵は暗号化のための鍵として用いられ、また、更新メッセージ内のデータにＭＡＣを付加する場合には、セッション鍵はＭＡＣを生成するための鍵として用いられる。
　ステップＳ１００４に続いて、マスタＥＣＵ１００の送受信部１０１は、セッション鍵を外部ツール３０ａの公開鍵で暗号化して、暗号化の結果である暗号化セッション鍵と、マスタＥＣＵ１００の公開鍵証明書４０ｃとを外部ツール３０ａへと送信する（ステップＳ１００５）。
　外部ツール３０ａでは、マスタＥＣＵ１００の公開鍵証明書４０ｃの検証を行う（ステップＳ１００６）。検証に失敗すれば、エラー処理を行う（ステップＳ１００７）。また、検証に成功すれば、外部ツール３０ａは、ステップＳ１００４においてマスタＥＣＵ１００から送信されて受信した暗号化セッション鍵を、外部ツール３０ａの保持する秘密鍵で復号して、セッション鍵を取得する（ステップＳ１００８）。
　ステップＳ１００８の次に、外部ツール３０ａは、メッセージＩＤ「０ｘ１０２」が付された、共有鍵６０ｄの更新用の更新メッセージを生成し、セッション鍵を用いて更新メッセージに暗号処理を実施する（ステップＳ１００９）。更新メッセージへの暗号処理の例としては、データフィールドに、例えば共有鍵６０ｄの更新に必要なデータ（例えばＥＣＵ４００ａにおいて鍵付きハッシュ関数等により更新を行うこととした場合においてはその鍵となるデータ）を格納しそのデータを暗号化する或いはそのデータにＭＡＣを付加する等が挙げられる。また、共有鍵６０ｄの更新にデータを必要としない場合であっても例えば更新メッセージの全体又は一部に対応したＭＡＣをデータフィールドに格納することも可能である。例えば、車載ネットワークシステム１０において、更新メッセージに対応する暗号処理としてどのような処理を行うかについて、行うべき所定暗号処理（つまりセッション鍵を用いた所定暗号処理）を、予め規定しておく。そして、各ＥＣＵはその規定に従って所定暗号処理（例えばＭＡＣの付加）が適切に（つまりセッション鍵を用いた検証に成功するように）実施されている更新メッセージに対応して更新を行い、所定暗号処理が適切に実施されていなければその更新メッセージに対しては更新を抑止する。
　外部ツール３０ａは、ステップＳ１００９で生成した更新メッセージをマスタＥＣＵ１００に送信する（ステップＳ１０１０）。
　ステップＳ１０１０で外部ツール３０ａが送信することでマスタＥＣＵ１００の送受信部１０１が受信したメッセージ（フレーム）のメッセージＩＤが受信すべきＩＤであるか否かを判定部１０３は、受信ＩＤ判断部１３０により判別する（ステップＳ１０１１）。共有鍵の更新用のメッセージＩＤ「０ｘ１００」～「０ｘ１０４」及びファームウェアの更新用のメッセージＩＤ「０ｘ２００」～「０ｘ２０６」は受信すべきＩＤであると判別される。ここでは、外部ツール３０ａが更新メッセージを送信することを想定して説明しているので、外部ツール３０ａからのメッセージ（フレーム）を更新メッセージと称しているが、実際には更新メッセージではないことも、あり得るため、ステップＳ１０１１で判別が行われる。つまり、外部ツール３０ａから送信されたメッセージ（フレーム）が、実際に更新メッセージであれば受信すべきと判別されることになる。なお、ここでは説明の便宜上、診断ポート６００に接続された外部ツール３０（例えば外部ツール３０ａ等）からマスタＥＣＵ１００は、更新メッセージ以外のメッセージについてのメッセージＩＤを受信すべきＩＤとして取り扱わないこととしている。
　ステップＳ１０１１において、送受信部１０１が受信したメッセージのメッセージＩＤが、受信すべきＩＤでないと判定した場合には、マスタＥＣＵ１００の判定部１０３は、そのメッセージＩＤのメッセージに係る処理を中止し、送受信部１０１ではＩＤフィールド以降の内容（データフィールド等）を受信せずに処理を終える（ステップＳ１０１２）。
　ステップＳ１０１１において、送受信部１０１が受信したメッセージのメッセージＩＤが、受信すべきＩＤであると判定した場合には、マスタＥＣＵ１００の判定部１０３は、受信したメッセージのメッセージＩＤ「０ｘ１０２」と外部ツール３０ａの公開鍵証明書４０ａに記載された更新権限情報のレベルとが、レベル情報保持部１０４に保持されているレベル情報１０４０におけるメッセージＩＤ１０４１とレベル１０４２との対応関係と合致するか否かにより、受信したメッセージが、許可される更新メッセージであるか否かを判定する（ステップＳ１０１３）。即ち、判定部１０３は、外部ツール３０ａによる更新メッセージの送信が外部ツール３０ａの権限範囲内であることを更新権限情報が示すか否かをレベル情報１０４０に基づいて判定する。受信したメッセージが許可される更新メッセージでなければエラー処理を行う（ステップＳ１０１４）。ステップＳ１０１４でのエラー処理により、更新メッセージに対応した更新は抑止される。ここでは、公開鍵証明書４０ａの更新権限情報のレベルが３である（図３参照）とすると、メッセージＩＤ「０ｘ１０２」の更新メッセージとの対応関係は、レベル情報１０４０が示す対応関係（図８参照）に合致するので、判定部１０３は、外部ツール３０ａから受信した更新メッセージが、許可される更新メッセージであると判定する。
　ステップＳ１０１３において、受信したメッセージの送信が外部ツール３０ａの権限範囲内であると判定した場合（つまり受信したメッセージが許可される更新メッセージであると判定した場合）には、判定部１０３は、フレーム生成部１２０へ転送用の更新メッセージを生成するよう指示する（ステップＳ１０１５）。これによりフレーム生成部１２０では、マスタＥＣＵ１００が外部ツール３０ａから受信した、元の更新メッセージに基づいて、バス５００ｂへの転送用（つまり他のＥＣＵへの転送用）に新たな更新メッセージ（フレーム）を生成する。例えば、マスタＥＣＵ１００が外部ツール３０ａとの通信に用いるセッション鍵と、他のＥＣＵ（少なくともバス５００ｂに接続された各ＥＣＵ）との通信に用いるセッション鍵とを異ならせている場合においては、フレーム生成部１２０は、元の更新メッセージに施された暗号処理が暗号化であれば復号を外部ツール３０ａとの通信用のセッション鍵を用いて行い、その処理の結果に他のＥＣＵとの通信に用いるセッション鍵を用いて暗号化を施すことで新たな更新メッセージを生成する。また、元の更新メッセージに施された暗号処理がＭＡＣの付加であれば、フレーム生成部１２０は、他のＥＣＵとの通信に用いるセッション鍵を用いてＭＡＣを生成して元の更新メッセージのＭＡＣを生成したＭＡＣで置き換えることで新たな更新メッセージを生成する。この場合において、元の更新メッセージのＭＡＣについて検証を行って検証に失敗した場合にエラー処理を行っても良い。また、例えば、マスタＥＣＵ１００が外部ツール３０ａとの通信に用いるセッション鍵と、他のＥＣＵとの通信に用いるセッション鍵とを同一にしている場合においては、フレーム生成部１２０は、元の更新メッセージと同一の新たな更新メッセージを生成する。
　ステップＳ１０１５に続いて、マスタＥＣＵ１００のフレーム生成部１２０が生成した更新メッセージをフレーム送受信部１６０がバス５００ｂに送出する（ステップＳ１０１６）。即ち、マスタＥＣＵ１００は、外部ツール３０ａから更新メッセージが送信された場合において、更新権限情報の検証（つまり公開鍵証明書の検証）が成功しており、かつ、更新メッセージの送信が外部ツール３０ａの権限範囲内であることを更新権限情報が示すときには、更新メッセージをバス５００ｂに転送する。なお、更新権限情報の検証が失敗していたとき、又は、更新メッセージの送信が外部ツール３０ａの権限範囲内であることを更新権限情報が示さないときには、更新メッセージのバス５００ｂへの転送は行われない。
　マスタＥＣＵ１００によりバス５００ｂに送出された更新メッセージは、ゲートウェイ３００によりバス５００ａ及びバス５００ｃに転送される。これにより、ＥＣＵ４００ａ～４００ｆは、更新メッセージを受信可能になる。従って、あるメッセージＩＤの更新メッセージの送信が外部ツール３０ａの権限範囲内であることを更新権限情報が示すとマスタＥＣＵ１００が判定したときには、そのメッセージＩＤの更新メッセージを受信するように予め定められているＥＣＵにより、更新メッセージに対応した更新が実行され得る。
　ＥＣＵ４００ａ（図９参照）では、フレーム送受信部４６０により更新メッセージを受信し、フレーム解釈部４５０でそのメッセージの内容を解釈し、受信すべきＩＤがどうかを受信ＩＤ判断部４３０へ問い合わせる。受信ＩＤ判断部４３０は、受信ＩＤリスト保持部４４０が保持している受信ＩＤリストを参照し、受信したメッセージのＩＤフィールドの値が、受信すべきＩＤかどうかを判断する（ステップＳ１０１７）。受信ＩＤ判断部４３０が、ステップＳ１０１７において、フレーム送受信部４６０により受信されたメッセージのメッセージＩＤが、受信すべきＩＤでないと判定した場合には、フレーム解釈部４５０は、その受信されたメッセージに係る処理を中止し、フレーム送受信部４６０ではＩＤフィールド以降の内容を受信せずに処理を終える（ステップＳ１０１８）。
　受信ＩＤ判断部４３０が、ステップＳ１０１７において、フレーム送受信部４６０により受信されたメッセージのＩＤフィールドの値が、受信すべきＩＤであると判断した場合は、ＥＣＵ４００ａは、フレーム処理部４１０により、そのメッセージ（つまり更新メッセージ）に対応した処理（つまり共有鍵６０ｄの更新）を実行する（ステップＳ１０１９）。フレーム処理部４１０では、現在、鍵保持部４０２が保持している共有鍵６０ｄから、更新メッセージのデータフィールド内の鍵データを用いて鍵付きハッシュ関数により、更新後となる新たな共有鍵６０ｄを生成する。更新には必ずしも鍵付きハッシュ関数を利用する必要はなく、他の例としては、鍵のないハッシュ関数（一方向性関数）を用いて元の共有鍵を新たな共有鍵に更新することが挙げられる。なお、ＥＣＵ４００ａにおいて、更新メッセージに施された暗号処理（暗号化或いはＭＡＣ付加）に対応する処理（復号或いはＭＡＣ検証）を、セッション鍵を用いて行って更新メッセージの鍵データを取得する。
　ＥＣＵ４００ａは、共有鍵６０ｄの更新後に更新の結果を示すメッセージ（更新結果メッセージと称する）をマスタＥＣＵ１００に伝達されるようにバス５００ａに送出する（Ｓ１０２０）。なお、更新結果メッセージのメッセージＩＤは予め定められており、マスタＥＣＵ１００は更新結果メッセージのメッセージＩＤを受信ＩＤリスト保持部１４０のリストに保持している。更新結果メッセージは、例えば更新を完了した旨（つまり更新成功の旨）を示す。なお、更新に際してエラーが生じたような場合（例えば鍵データのＭＡＣ検証に失敗した場合等）には更新結果メッセージが更新失敗の旨を示すようにしても良い。更新結果メッセージは、ゲートウェイ３００によりバス５００ａからバス５００ｂに転送される。
　マスタＥＣＵ１００は、更新結果メッセージを受信すると、鍵保持部１０２が保持している共有鍵６０ｄ（図６参照）をＥＣＵ４００ａと同様の方法で更新する（ステップＳ１０２１）。なお、マスタＥＣＵ１００は、例えばＥＣＵ４００ａからの更新成功の旨を示す更新結果メッセージとＥＣＵ４００ｂからの更新成功の旨を示す更新結果メッセージとの両方を受けた場合に限って、鍵保持部１０２が保持している共有鍵６０ｄを更新するようにしても良い。
　マスタＥＣＵ１００は、ステップＳ１０２０において受信した更新結果メッセージを、バス５００ｄに送出することで診断ポート６００を介して外部ツール３０ａに送信する（ステップＳ１０２２）。これにより、外部ツール３０ａでは更新結果メッセージを受信して、車載ネットワークシステム１０において目的な更新が完了したこと等を知り、例えば更新の完了を利用者に報知（例えば外部ツール３０ａが表示装置を有していれば表示等）し得る。
　以上、外部ツール３０ａが、ＥＣＵ４００ａ、４００ｂ及びマスタＥＣＵ１００のそれぞれが保持する共有鍵６０ｄの更新用の更新メッセージを送信する例を示したが、他のＥＣＵが保持する共有鍵の更新用の更新メッセージを送信した場合、或いは、ＥＣＵ内のファームウェアの更新用の更新メッセージを送信した場合においても、各装置は同様の動作を行う。なお、外部ツール３０ａは認証要求を１度送信した後において、各更新メッセージを逐次送信しても良い。この場合には、ステップＳ１００１からステップＳ１００８までの処理が一度実行された後に、外部ツール３０ａが各更新メッセージを送信する毎に、ステップＳ１００９以降の処理が繰り返されるようになる。また、ＥＣＵ内のファームウェアの更新用の更新メッセージは、例えば更新後のファームウェアの内容を特定するための情報を含み、更新メッセージの対象となるＥＣＵでは、その更新後のファームウェアの内容を特定するための情報に基づいてファームウェアを書き換える。ファームウェアは、例えば、ＥＣＵ内のプログラム等のソフトウェア、プログラムで用いられるデータを含み、例えば、ＥＣＵ内のプロセッサにおけるマイクロコードを含み得る。またファームウェアは、例えばＥＣＵがＦＰＧＡ（Field Programmable Gate Array）等を含む場合において、回路構成用のデータを含み得る。また、ここでの説明では便宜上、共有鍵とファームウェアとは別々に扱ったが、ファームウェアが共有鍵を含むと扱っても良い。
　［１．１２　実施の形態１の効果］
　実施の形態１に係る車載ネットワークシステム１０では、診断ポート６００に接続される外部ツール３０が特定のＥＣＵ内のデータを更新する更新メッセージの送信権限を有するか否か、つまり外部ツール３０が特定のＥＣＵ内のデータを更新する権限を有するか否かを、外部ツール３０に対して認定された権限を示す更新権限情報が示す、ＥＣＵの機能種別に対応して定められたレベルに基づいて、判定している。これにより、不正な外部ツールによるＥＣＵ内の共有鍵或いはファームウェアの更新を防ぐことができる。また。外部ツール毎に、例えば外部ツールの機密性、信頼性、外部ツールを扱う事業者の信頼性その他の各種事情に応じて、更新権限情報のレベルを異ならせて設定（及び認定）できる。レベルを変えた外部ツールを別々のメンテナンス業者等に対して配布することも可能となり、各種事情に応じて柔軟に更新権限を制限した運用が可能になる。例えば、機密性、信頼性等のセキュリティ確保が十分である外部ツールほど、高い権限のレベルを認定する等が可能となる。このように外部ツール毎に更新権限情報のレベルを設定できることは、外部ツールを用途等に応じて効率的に柔軟に設計及び製造するために、或いは、外部ツールの運用上のセキュリティ確保等を用途に応じて柔軟に行うために、有用となる。
　（実施の形態２）
　以下、実施の形態１で示した車載ネットワークシステム１０を一部変形してなる車載ネットワークシステム１０ａについて説明する。
　実施の形態１に係る車載ネットワークシステム１０では、診断ポート６００に外部ツール３０が接続された場合においてマスタＥＣＵ１００が、外部ツール３０を認証して、外部ツール３０からの更新メッセージが、更新権限情報が示す権限（レベル）の範囲内である場合に限って、外部ツール３０にその更新メッセージでＥＣＵ内のデータを更新することを許可した。
　本実施の形態に係る車載ネットワークシステム１０ａでは、外部ツール３０の更新メッセージを許可するか否かの判定において、レベルだけでなく車載ネットワークシステム１０ａを搭載している車両の状態、及び、車両における電池の残量の状態を参照する。本実施の形態に係る車載ネットワークシステム１０ａの構成は概ね実施の形態１で示した車載ネットワークシステム１０（図１参照）と同様であり、以下、実施の形態１と同様のものについて同じ符号を用いる。
　［２．１　車載ネットワークシステム１０ａの全体構成］
　図１３は、実施の形態２に係る車載ネットワークシステム１０ａの全体構成を示す図である。なお、同図には車載ネットワークシステム１０ａの他に、外部ツール３０が示されている。
　車載ネットワークシステム１０ａでは、車載ネットワークシステム１０（図１）に対して、蓄電池８００とＥＣＵ４００ｇとが追加されている。ここでは、実施の形態１と同様な構成要素の説明を省略する。
　ＥＣＵ４００ｇは、バス５００ｂと接続され、電池（蓄電池）８００の充放電に係る制御を行い、蓄電池８００の残量を取得して管理し、定期的に電池残量の状態を表すフレームをネットワーク（つまりバス５００ｂ）に送信している。
　蓄電池８００は、車載ネットワークシステム１０における各ＥＣＵへ電力を供給する。
　［２．２　レベル情報］
　図１４は、実施の形態２におけるマスタＥＣＵ１００のレベル情報保持部１０４が保持するレベル情報２０４０の一例を示す図である。
　レベル情報２０４０は、メッセージＩＤ２０１４とレベル２０４２と電池残量条件２０４３と車両状態条件２０４４とを対応付けた情報であり、判定部１０３において外部ツール３０からの更新メッセージを許可するか否かの判定に用いられる。メッセージＩＤ２０４１及びレベル２０４２は、実施の形態１で示したメッセージＩＤ１０４１及びレベル１０４２と同様である。電池残量条件２０４３は、更新メッセージを許可するために必要とされる電池の残量の条件を示し、例えば、電池の残量が更新に足りる程度に十分な量に設定され、具体例としては満充電の充電量を１００％として充電５０％以上の残量及び充電８０％以上の残量のいずれかが設定される。また、車両状態条件２０４４は、更新メッセージを許可するために必要とされる車両状態の条件を示し、例えば停車状態（車両の速度がゼロとなっている状態）及びエンジンＯＦＦ状態（エンジン３１０を停止した状態）のいずれかが設定される。
　例えば、メッセージＩＤ「０ｘ１０４」の共有鍵の更新用の更新メッセージは、更新権限情報のレベルが１又はそれ以上で、蓄電池８００の電池残量が充電５０％以上で、且つ、車両状態が停車状態であるときに許可されることを示している。また、メッセージＩＤ「０ｘ２０１」のファームウェアの更新用の更新メッセージは、更新権限情報のレベルが４で、蓄電池８００の電池残量が充電８０％以上で、且つ、車両状態がエンジンＯＦＦ状態であるときに許可されることを示している。
　［２．３　共有鍵更新シーケンス］
　以下、更新管理方法の一例として、外部ツール３０ａを診断ポート６００に接続して、外部ツール３０ａから車載ネットワークシステム１０ａにおけるＥＣＵが保持する共有鍵を更新させる場合の動作（共有鍵更新シーケンス）について、図１５及び図１６を用いて説明する。
　図１５及び図１６は、外部ツール３０ａとマスタＥＣＵ１００とＥＣＵ４００ａとの間で行われる共有鍵更新シーケンスの一例を示す図である。ここでは、便宜上、外部ツール３０の１つとしての外部ツール３０ａ、及び、ＥＣＵ４００ａ～４００ｇのうちの１つであるＥＣＵ４００ａに注目して説明する。また、駆動系機能及びシャーシ系機能を有する各ＥＣＵが保持する共有鍵を更新するために外部ツール３０ａが用いられる場面を想定して説明する。具体的には、駆動系機能を有するＥＣＵ４００ａ及びシャーシ系機能を有するＥＣＵ４００ｂのそれぞれが保持する共有鍵６０ｄの更新のためのメッセージＩＤ「０ｘ１０２」が付された更新メッセージが外部ツール３０ａから車載ネットワークシステム１０へと送信されることになる。ＥＣＵ４００ｂの動作は、ＥＣＵ４００ａの動作と同様であるため、ここでは説明を省略する。また、ステップＳ２００１からステップＳ２０１２とステップＳ２０１４からステップＳ２０２２との処理は、実施の形態１で示したステップＳ１００１からステップＳ１０１２とステップＳ１０１４からステップＳ１０２２との処理（図１１及び図１２参照）と同等なので説明を省略し、ここでは、実施の形態１と異なるステップＳ２０１３ａ～Ｓ２０１３ｃのみを説明する。
　ステップＳ２０１３ａでは、マスタＥＣＵ１００の判定部１０３は、受信したメッセージのメッセージＩＤ「０ｘ１０２」と外部ツール３０ａの公開鍵証明書４０ａに記載された更新権限情報のレベルとが、レベル情報保持部１０４に保持されているレベル情報２０４０におけるメッセージＩＤ２０４１とレベル２０４２との対応関係と合致するか否かにより、受信したメッセージが、適切な更新メッセージとして権限のレベルについての条件を満たすか否かを判定する。即ち、判定部１０３は、外部ツール３０ａによる更新メッセージの送信が外部ツール３０ａの権限範囲内であることを更新権限情報が示すか否かをレベル情報２０４０に基づいて判定する。受信したメッセージが権限のレベルについての条件を満たさない場合にはエラー処理を行う（ステップＳ２０１４）。ここでは、公開鍵証明書４０ａの更新権限情報のレベルが３である（図３参照）とすると、メッセージＩＤ「０ｘ１０２」の更新メッセージとの対応関係は、レベル情報２０４０が示す対応関係（図１４参照）に合致するので、判定部１０３は、外部ツール３０ａから受信した更新メッセージが、レベルの点で適切な更新メッセージであると判定し、次のステップＳ２０１３ｂへ処理を移す。
　ステップＳ２０１３ｂでは、判定部１０３は、蓄電池８００の電池残量が条件を満たすか否かをチェックする。蓄電池８００の電池残量を管理するＥＣＵ４００ｇが定期的に電池残量の状態を示すメッセージ（電池残量フレームと称する）を送信している場合において、マスタＥＣＵ１００は、ＥＣＵ４００ｇからの電池残量フレームをフレーム送受信部１６０で受信する。なお、マスタＥＣＵ１００の受信ＩＤリスト保持部１４０が保持する受信ＩＤリストには、ＥＣＵ４００ｇからの電池残量フレームのメッセージＩＤが含まれているものとする。判定部１０３は、ＥＣＵ４００ｇから受信した電池残量フレームが示す電池残量が、レベル情報保持部１０４に保持されているメッセージＩＤ２０４１に対応する電池残量条件２０４３を満たすか否かをチェックする。電池残量の条件が満たされていれば、次のステップＳ２０１３ｃへ処理を移す。電池残量の条件が満たされていない場合（つまりチェックの結果がＮＧである場合）には、エラー処理を行う（ステップＳ２０１４）。なお、ＥＣＵ４００ｇが定期的に電池残量の状態を示す電池残量フレームを送信しないこととしても良く、この場合には、ステップＳ２０１３ｂにおいてマスタＥＣＵ１００は、例えばＥＣＵ４００ｇに電池残量フレームの送信を依頼するフレームを送信することで、ＥＣＵ４００ｇから電池残量フレームを受信して、更新メッセージが受信された時（つまり現在）における電池残量の状態を取得しても良い。
　ステップＳ２０１３ｃでは、判定部１０３は、車両状態が条件を満たすか否かをチェックする。エンジン３１０に係るＥＣＵ４００ａがエンジン状態や車速等の車両状態情報を示すメッセージ（車両状態フレームと称する）を定期的に送信している場合において、マスタＥＣＵ１００は、ＥＣＵ４００ａからの車両状態フレームをフレーム送受信部１６０で受信する。なお、マスタＥＣＵ１００の受信ＩＤリスト保持部１４０が保持する受信ＩＤリストには、ＥＣＵ４００ａからの車両状態フレームのメッセージＩＤが含まれているものとする。判定部１０３は、ＥＣＵ４００ａから受信した車両状態フレームが示すエンジン状態、車速等の車両状態が、レベル情報保持部１０４に保持されているメッセージＩＤ２０４１に対応する車両状態条件２０４４を満たすか否かをチェックする。車両状態の条件が満たされていれば、判定部１０３は、外部ツール３０ａから受信した更新メッセージが許可されるものであると判定し、ステップＳ２０１５へと処理を移す。また、車両状態の条件が満たされていない場合（つまりチェックの結果がＮＧである場合）には、エラー処理を行う（ステップＳ２０１４）。なお、ＥＣＵ４００ａが定期的に車両状態フレームを送信しないこととしても良く、この場合には、ステップＳ２０１３ｃにおいてマスタＥＣＵ１００は、例えばＥＣＵ４００ａに車両状態フレームの送信を依頼するフレームを送信することで、ＥＣＵ４００ａから車両状態フレームを受信して、更新メッセージが受信された時（つまり現在）における車両状態を取得しても良い。
　［２．４　実施の形態２の効果］
　実施の形態２に係る車載ネットワークシステム１０ａでは、外部ツール３０からの更新メッセージに係る処理（更新）を許可するか否かについて、権限のレベルだけでなく電池残量の状態及び車両状態がどのような場合に更新メッセージが送信されたかに応じて判定している。このため、実施の形態１に係る車載ネットワークシステム１０の効果に加え、次の効果を有する。即ち、電池残量を確認することで、ＥＣＵ内のデータ（共有鍵或いはファームウェア）の更新処理が途中で途切れることなく確実に完了させられる。また、車両状態を確認することで、例えば、車両の走行中等のＥＣＵの負荷が高くバストラフィックが増大するときに更新メッセージを転送して更新を行うことを回避でき、更新が成功する可能性を高められる。
　（実施の形態３）
　本実施の形態では、実施の形態１に係る車載ネットワークシステム１０におけるマスタＥＣＵ１００を部分的に変形し、共有鍵の有効期限に係る報知を行えるようにした例について説明する。
　［３．１　マスタＥＣＵ（更新管理装置）１００ａの構成］
　図１７は、マスタＥＣＵ１００ａの構成図である。マスタＥＣＵ１００ａは、実施の形態１で示したマスタＥＣＵ１００の構成要素に、共有鍵の有効期限をチェックするために、時刻情報取得部１８０と鍵更新確認部１９０とを加えた構成を有する。これらの各構成要素は、機能的な構成要素であり、その各機能は、マスタＥＣＵ１００ａにおける通信回路、メモリに格納された制御プログラムを実行するプロセッサ或いはデジタル回路等により実現される。ここでは、実施の形態１で示した構成要素についての説明を省略する。
　時刻情報取得部１８０は、例えばリアルタイムクロック等の計時機構で構成され、現在時刻（つまり現在の日時）を取得して鍵更新確認部１９０に逐次通知する。
　鍵更新確認部１９０は、時刻情報取得部１８０から通知された現在時刻と、鍵保持部１０２が保持している共有鍵について予め定めている有効期限を確認し、予めアラート通知タイミングとして設定されているタイミングを過ぎた時点（つまり有効期限の一定期間前）に、鍵更新アラートメッセージを、フレーム生成部１２０に生成させてフレーム送受信部１６０から送信させる。
　図１８に、鍵保持部１０２が保持している共有鍵それぞれについて、共有鍵識別情報３３１０と有効期限３３１１とアラート通知タイミング３３１２とを対応付けた情報の一例を示す。共有鍵識別情報３３１０は、各共有鍵を区別する情報である。有効期限３３１１は、対応する共有鍵識別情報が指す共有鍵についてセキュリティの確保のために予め定められた有効期限を示す。アラート通知タイミング３３１２は、有効期限より先行して鍵更新を促すべきタイミングを示す。鍵更新確認部１９０は、この図１８に示す情報を参照する。例えば、共有鍵６０ａであれば、有効期限の３ヶ月前から鍵更新アラートメッセージを送信し、共有鍵６０ｄであれば、有効期限の１ヶ月前から鍵更新アラートメッセージを送信する。
　鍵更新アラートメッセージは、ヘッドユニット２００に接続されたＥＣＵ４００ｆにより受信される。ＥＣＵ４００ｆは、鍵更新アラートメッセージを受信すると、共有鍵の有効期限が近付いている旨等を示す、共有鍵の更新を促す警告情報（画面）をヘッドユニット２００の表示装置に表示する。
　［３．２　鍵更新アラートメッセージ］
　図１９は、共有鍵の有効期限が近付いた場合に、ヘッドユニット２００の表示装置に表示される画面の一例を示す図である。
　図１９の例では、画面３３２０は、現在日時とＥＣＵの共有鍵の有効期限とを含み、更に、共有鍵の更新を行うためのメンテナンス業者（この例ではディーラー）の連絡先、そのウェブサイトのＵＲＬ（Uniform Resource Locator）を含む。また、画面３３２０は、ナビゲーションシステムにより目的地をディーラーの住所に設定する画面へ遷移するためのＧＵＩ（Graphical User Interface）のボタン３３２１を含む。なお、このディーラーの情報については、例えば販売時等において予めマスタＥＣＵ１００ａに登録されていても良いし、テレマティクス系機能を有するＥＣＵを介して取得しても良い。
　例えば、図１９に例示する画面３３２０を見た運転者が車両を運転して、ディーラー等のメンテナンス業者へ行けば、ディーラー等は、実施の形態１、２等で説明したように、外部ツール３０を用いて車載ネットワークシステムにおけるＥＣＵが保持する共有鍵の更新を実行させ得る。
　［３．３　実施の形態３の効果］
　実施の形態３に係る車載ネットワークシステムにおいては、共有鍵の有効期限を管理し、有効期限が近付いた場合に、車両の運転者等に鍵更新を促すような警告情報（画面）をヘッドユニットの表示装置に表示する。これにより、ディーラー等でのメンテナンスを受けるべきことの警告等といった共有鍵に係るセキュリティを確保するための注意喚起が実現される。
　（実施の形態４）
　本実施の形態では、実施の形態１に係る車載ネットワークシステム１０におけるマスタＥＣＵ１００を、更新結果メッセージに車両識別情報を付して外部ツール３０へ送信するように変形し、外部ツール３０がサーバ３５と通信するようにした例について説明する。
　［４．１　サーバ］
　外部ツール３０と通信するサーバ３５は、車載ネットワークシステム１０が搭載される車両の外部に所在するコンピュータである。複数の車両それぞれに車載ネットワークシステム１０が搭載されていることを前提として、サーバ３５は、外部ツール３０が、どの車両（つまり車載ネットワークシステム）に対して、どのような更新（ＥＣＵ内のデータの更新）を行ったかを管理する。
　［４．２　共有鍵更新シーケンス］
　以下、本実施の形態での更新管理方法の一例として、サーバ３５と通信する外部ツール３０ａを、ある車両の車載ネットワークシステム１０における診断ポート６００に接続して、外部ツール３０ａから車載ネットワークシステム１０におけるＥＣＵが保持する共有鍵を更新させる場合の動作（共有鍵更新シーケンス）について、図２０及び図２１を用いて説明する。
　図２０及び図２１は、サーバ３５と通信する外部ツール３０ａとマスタＥＣＵ１００とＥＣＵ４００ａとの間で行われる共有鍵更新シーケンスの一例を示す図である。ステップＳ３００１からステップＳ３０２１までの処理は、実施の形態１で示したステップＳ１００１からステップＳ１０２１までの処理（図１１及び図１２参照）と同等なので説明を省略し、ここでは、実施の形態１と異なるステップＳ３０００ａ、Ｓ３０００ｂ、Ｓ３０２２、Ｓ３０２３及びＳ３０２４のみを説明する。
　ステップＳ３０００ａでは、外部ツール３０ａは、サーバ３５に接続要求を出す。即ち外部ツール３０ａは、例えば予め登録されたＩＤ（例えばツールＩＤ）及びパスワードを用いたログイン要求をサーバ３５に送信する。
　ステップＳ３０００ｂでは、サーバ３５は、外部ツール３０ａからの接続要求を受け、ＩＤ及びパスワードが予め登録されている情報と一致すればログイン処理を行って正常応答を返信する。
　ステップＳ３０００ｂの後において、外部ツール３０ａ、マスタＥＣＵ１００及びＥＣＵ４００ａは、実施の形態１で説明した通りに共有鍵の更新に係る処理を行う。これにより、ステップＳ３０２０では、マスタＥＣＵ１００がＥＣＵ４００ａからの更新結果を示す更新結果メッセージを受信している。
　ステップＳ３０２２では、マスタＥＣＵ１００は、ＥＣＵ４００ａからの更新結果に加えて、車両識別情報を含めたメッセージである車両識別情報付き更新結果メッセージをバス５００ｄに送出することで診断ポート６００を介して外部ツール３０ａに送信する。これにより、外部ツール３０ａでは車両識別情報付き更新結果メッセージを受信する。車両識別情報は、この外部ツール３０ａが接続している車載ネットワークシステムを複数の車載ネットワークシステムの中で識別する情報であれば足り、例えばマスタＥＣＵ１００の公開鍵証明書４０ｃ（図３参照）等である。
　ステップＳ３０２３では、外部ツール３０ａは、受信した車両識別情報付き更新結果メッセージが示す車両識別情報及び更新結果をサーバ３５に送信する。
　ステップＳ３０２４では、サーバ３５は、受信した車両識別情報及び更新結果と、現在日時と、ログイン時に受信していたＩＤと対応付けてログ情報４０００として保存する。
　［４．３　診断ログ情報］
　図２２は、サーバ３５が保存するログ情報４０００の一例を示す図である。ログ情報４０００は、車両識別情報４００１と、外部ツールＩＤ４００２と、更新メッセージのメッセージＩＤ４００３と、日時４００４と、更新結果４００５とを含む。
　［４．４　実施の形態４の効果］
　本実施の形態では、サーバ３５が、ログ情報４０００を保存し、どの車両がどの外部ツールによって更新されたか等の情報が残るので、メンテナンス状況の把握が可能となる。また、不正な外部ツールが発見された場合にその外部ツールによる影響範囲の特定のためにログ情報４０００が利用できる。
　（他の実施の形態）
　以上のように、本発明に係る技術の例示として実施の形態１～４を説明した。しかしながら、本発明に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本発明の一実施態様に含まれる。
　（１）上記実施の形態で示した共有鍵は、機能を分類する機能種別により共有範囲を区別している例を示したが、これに限定されることはなく、マスタＥＣＵとその他の１又は複数のＥＣＵとが共有鍵を持ち合う単位は、車載ネットワークシステムにおいて任意に定め得る。例えば、車内ネットワークを複数のドメインに分けてドメイン毎に共有鍵を設定しても良い。その場合、更新のために必要な権限のレベルとしてドメインを区別してレベル情報を設定しても良い。また、上記実施の形態では、外部ツール３０が、機能種別を踏まえて権限のレベルを設定された更新権限情報を含む公開鍵証明書を有する例を示したが、自動車メーカや車種に対応した更新の権限が設定された更新権限情報を含む公開鍵証明書を有しても良い。
　（２）上記実施の形態では、共有鍵の更新は、現在各ＥＣＵが保持している共有鍵から鍵付きハッシュ関数を利用して新たな共有鍵を生成することで行うこととしたが、外部ツール３０が新たな共有鍵自体を更新メッセージに含めて送信しても良い。この場合、共有鍵の値がＣＡＮの１フレーム内に収まらない場合は、複数フレームに分割して送信するようにしても良い。
　（３）上記実施の形態では、外部ツール３０からＥＣＵ内のデータ（共有鍵、ファームウェア等）を更新するための更新メッセージを送信する例を示したが、この他に故障診断用等のメッセージを送信し得る。更新メッセージ以外のメッセージについては、車載ネットワークシステム（例えばマスタＥＣＵ）において、レベル情報に基づく権限の判定を行うことなく、メッセージに対応した処理をすることとしても良い。更に、故障診断用等のメッセージを含む任意のメッセージについて、車載ネットワークシステム（例えばマスタＥＣＵ）においてそのメッセージの送信が外部ツール３０に認められた権限範囲内であるかを権限のレベルを示す権限情報に基づいて判定することとしても良い。
　（４）上記実施の形態では、権限のレベルを１から４に設定しているが、レベルは、４段階でなくても良く、それ以上、それ以下に設定するようにしても良い。
　（５）上記実施の形態で示した機能種別の分類の仕方は一例に過ぎず、例えばより詳細に細分化しても良い。機能種別を最も細かく分類して例えばＥＣＵ毎にＥＣＵ内のデータの更新に係る権限のレベルを設定しても良い。
　（６）実施の形態２では、電池残量条件２０４３として蓄電池８００の満充電に対する割合（パーセント）により区別する例を示したが、蓄電池８００の電圧等で区別しても良い。また、車両の外部に所在する外部電源から蓄電池８００へ充電中か否かを区別する条件を設定しても良い。これにより、例えば、一定の共有鍵、ファームウェアの更新を充電中に限って許可すること等が実現できる。
　（７）実施の形態３では、共有鍵の有効期限が近付いた場合に、鍵更新アラートメッセージに基づき鍵更新の有効期限が近付いている旨等を示す情報（画面）を表示する例を示したが、その情報を繰り返し或いは継続的に表示しても良いし、有効期限が切れた場合に警告を報知（表示等）するようにしても良い。
　（８）実施の形態３では、共有鍵の有効期限切れの確認のために、マスタＥＣＵ１００ａの時刻情報取得部１８０が計時機構で現在時刻を取得する例を示したが、ＷｉＦｉ（登録商標）、携帯電話のキャリア網から現在時刻を示す時刻情報を取得しても、ＧＰＳ（Global Positioning System）信号から時刻情報を取得しても良い。また、マスタＥＣＵ１００ａが、他のＥＣＵから時刻情報を取得しても良い。
　（９）上記実施の形態で示した外部ツール３０は、更新メッセージを、サーバから受信することで取得して、診断ポート６００を介してマスタＥＣＵに転送しても良い。
　（１０）上記実施の形態では、外部ツール３０とマスタＥＣＵとの間で認証を行っているが、ＯＢＤ２に準拠したコネクタ等である診断ポート６００に、認証を担う電子回路（例えばメモリ、プロセッサ等）等を付加し、診断ポート６００において外部ツール３０の認証を行うこととしても良い。この場合に診断ポート６００により外部ツール３０の認証が完了していれば、マスタＥＣＵは外部ツール３０の認証を省略し得る。なお、診断ポート６００により外部ツール３０の認証が完了していても上記実施の形態で示したように外部ツール３０とマスタＥＣＵとの間で認証を行っても良い。なお、診断ポート６００を、ＯＢＤ２に準拠したコネクタ等でなく、他のコネクタで実現しても良い。また、診断ポート６００を、無線通信回路を含めて実現することで外部ツール３０との間で無線通信により接続できるようにしても良い。
　（１１）実施の形態２では、更新メッセージを受信したときにマスタＥＣＵ１００が電池残量の状態及び車両状態をチェックする例を示したが、電池残量及び車両状態のいずれか一方のみをチェックすることとしても良い。また、更新権限情報が権限のレベルを示すのみならず、実施の形態２で示した電池残量条件、車両状態条件等といった更新権限についての条件をも示すこととしても良い。例えば、更新権限情報は、車両状態条件として車両の状態である停車状態、又は、エンジンを停止した状態を特定し、車両が、特定したその状態であるときに更新メッセージを送信することを少なくとも１つの条件としてＥＣＵに更新を行わせる権限を外部ツールが有することを表すこととしても良い。また、例えば、更新権限情報は、電池残量条件としてＥＣＵに電力を供給する電池の残量の状態を特定し、その電池が、特定したその電池残量を有する状態であるときに更新メッセージを送信することを少なくとも１つの条件としてＥＣＵに更新を行わせる権限を外部ツールが有することを表すこととしても良い。そして、例えば、マスタＥＣＵ１００は、レベル情報２０４０における電池残量条件２０４３及び車両状態条件２０４４の代わりに、更新権限情報が示す電池残量条件、車両状態条件に基づいてチェック（ステップＳ２０１３ｂ、Ｓ２０１３ｃ）を行うようにしても良い。これにより、外部ツールに対して、外部ツールの信頼性等に応じて、一定の条件を付した権限を認定して、その条件及び権限のレベルを示す更新権限情報を記載した公開鍵証明書を発行するような運用が可能になる。
　（１２）上記実施の形態では、ＣＡＮプロトコルにおけるデータフレームを標準ＩＤフォーマットで記述しているが、拡張ＩＤフォーマットで合っても良い。拡張ＩＤフォーマットの場合には、標準ＩＤフォーマットにおけるＩＤ位置のベースＩＤと、拡張ＩＤとを合わせて２９ビットでメッセージＩＤを表す。
　（１３）上記実施の形態では、外部ツール３０が接続される診断ポート６００とマスタＥＣＵとを繋ぐバス５００ｄには他のＥＣＵが接続されていない例を示したが、ＥＣＵを接続しても良い。但し、マスタＥＣＵ以外でバス５００ｄに接続されるＥＣＵはそのデータ（共有鍵、ファームウェア等）を、外部ツール３０（例えばマスタＥＣＵによる認証に成功してセッション鍵を得た外部ツール３０）が送信する更新メッセージにより更新され得る。このため、例えば、更新の権限のレベルとして最も低いレベルに対応する機能種別の機能を有するＥＣＵ等に限ってバス５００ｄに接続することが有用となる。
　（１４）上記実施の形態では、外部ツール３０が、認められた権限のレベルを超えてＥＣＵに更新を指示する更新メッセージを送信した場合にマスタＥＣＵが、その更新メッセージが、許可される更新メッセージであるか否かを判定し（ステップＳ１０１３）、許可される更新メッセージでなければエラー処理を行って（ステップＳ１０１４）、更新メッセージに対応した更新を抑止することとした。しかし、マスタＥＣＵ以外のＥＣＵ（例えば更新メッセージによる更新の指示対象となるＥＣＵ）が、外部ツール３０の更新権限情報に基づいて、更新を実行するか抑止するかを切り替えるようにしても良い。即ち、車載ネットワークシステムのいずれかのＥＣＵにおいて、外部ツール３０から更新メッセージが送信された場合において、更新権限情報の検証が成功し、かつ、更新メッセージの送信が外部ツール３０の権限範囲内であることを更新権限情報が示すときには、更新メッセージに対応して１つ又は複数のＥＣＵにより更新を実行し、その検証が失敗したとき、又は、更新メッセージの送信が外部ツール３０の権限範囲内であることを更新権限情報が示さないときには、１つ又は複数のＥＣＵによる更新メッセージに対応した更新を抑止するようにしても良い。なお、実施の形態で示したようにマスタＥＣＵが一括して更新メッセージの転送を行うか否かを切り替える方式は、効率面で有用である。また、ゲートウェイ３００で転送先のバスに接続されたＥＣＵの機能種別或いはそのＥＣＵが受信可能なメッセージＩＤを管理することとし、ゲートウェイ３００が、更新メッセージを受信した場合に、転送先のバスに接続されたＥＣＵの機能種別或いはそのＥＣＵが受信可能なメッセージＩＤに基づいて、不要な更新メッセージの転送を行わないようにしても良い。
　（１５）上記実施の形態で示したマスタＥＣＵ１００、１００ａ、ＥＣＵ４００ａ等の機能構成は、一例に過ぎず、上述した機能構成とは異なる機能分割を行っても良い。例えば、マスタＥＣＵ１００、１００ａは、送受信部１０１の受信機能に相当する受信部、判定部１０３における公開鍵証明書（更新権限情報を含む公開鍵証明書）の検証を担当する検証部、判定部１０３の一部とフレーム生成部１２０の一部とフレーム送受信部１６０の一部とに相当して更新メッセージの送信に係る制御を行う転送部とを含むこととしても良い。この場合に、例えば、受信部は、診断ポート６００に接続された外部ツール３０から診断ポート６００を介して送信される、外部ツール３０の権限を示す更新権限情報、及び、１つ又は複数のＥＣＵが保持するデータの更新を指示する更新メッセージを受信する機能を担う。また、検証部は、受信部により受信された更新権限情報を検証する機能を担う。また、転送部は、受信部により更新メッセージが受信された場合において、検証部による検証が成功し、かつ、更新メッセージの送信が外部ツール３０の権限範囲内であることを更新権限情報が示すときには、更新メッセージをバス５００ｂに転送し、検証部による検証が失敗したとき、又は、更新メッセージの送信が外部ツール３０の権限範囲内であることを更新権限情報が示さないときには、転送を抑止する機能を担う。また、プロセッサを有するマスタＥＣＵ１００、１００ａにおいてプロセッサに実行される制御プログラムは、マスタＥＣＵ１００、１００ａに例えば次の所定の更新管理処理を実行させるためのプログラムであっても良い。所定の更新管理処理は、診断ポートに接続された外部ツールから診断ポートを介して送信される、その外部ツールの権限を示す更新権限情報を受信する更新権限情報受信ステップと、更新権限情報受信ステップにおいて受信された更新権限情報を検証する検証ステップと、外部ツールから診断ポートを介して送信される更新メッセージを受信する更新メッセージ受信ステップと、更新メッセージ受信ステップで更新メッセージが受信された場合において、検証ステップでの検証が成功しており、かつ、その更新メッセージの送信が外部ツールの権限範囲内であることを更新権限情報が示すときには、更新メッセージをＥＣＵとの通信用のバスに転送し、検証ステップでの検証が失敗したとき、又は、その更新メッセージの送信が外部ツールの権限範囲内であることを更新権限情報が示さないときには、転送を抑止する転送制御ステップとを含む。
　（１６）上記実施の形態におけるマスタＥＣＵ及び他のＥＣＵは、例えば、プロセッサ、メモリ等のデジタル回路、アナログ回路、通信回路等を含む装置であることとしたが、ハードディスク装置、ディスプレイ、キーボード、マウス等の他のハードウェア構成要素を含んでいても良い。また、メモリに記憶された制御プログラムがプロセッサにより実行されてソフトウェア的に機能を実現する代わりに、専用のハードウェア（デジタル回路等）によりその機能を実現することとしても良い。
　（１７）上記実施の形態における各装置を構成する構成要素の一部又は全部は、１個のシステムＬＳＩ（Large Scale Integration：大規模集積回路）から構成されているとしても良い。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等を含んで構成されるコンピュータシステムである。前記ＲＡＭには、コンピュータプログラムが記録されている。前記マイクロプロセッサが、前記コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。また、上記各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又は全部を含むように１チップ化されても良い。また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現しても良い。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡや、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。
　（１８）上記各装置を構成する構成要素の一部又は全部は、各装置に脱着可能なＩＣカード又は単体のモジュールから構成されているとしても良い。前記ＩＣカード又は前記モジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等から構成されるコンピュータシステムである。前記ＩＣカード又は前記モジュールは、上記の超多機能ＬＳＩを含むとしても良い。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、前記ＩＣカード又は前記モジュールは、その機能を達成する。このＩＣカード又はこのモジュールは、耐タンパ性を有するとしても良い。
　（１９）本発明の一態様としては、上記に示す共有鍵更新シーケンス等の更新管理方法であるとしても良い。また、これらの方法をコンピュータにより実現するコンピュータプログラムであるとしても良いし、前記コンピュータプログラムからなるデジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラム又は前記デジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Blu-ray（登録商標） Disc）、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されている前記デジタル信号であるとしても良い。また、本発明の一態様としては、前記コンピュータプログラム又は前記デジタル信号を、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本発明の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、前記メモリは、上記コンピュータプログラムを記録しており、前記マイクロプロセッサは、前記コンピュータプログラムに従って動作するとしても良い。また、前記プログラム若しくは前記デジタル信号を前記記録媒体に記録して移送することにより、又は、前記プログラム若しくは前記デジタル信号を前記ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしても良い。
　（２０）上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本発明の範囲に含まれる。
　本発明は、車載ネットワークにおいて外部ツールからのＥＣＵのファームウェア等の更新を管理して、不正な書き換え等のリスクを軽減するために利用可能である。
　１０，１０ａ　車載ネットワークシステム
　２０　鍵発行機関
　２１　メーカ
　３０，３０ａ，３０ｂ　外部ツール
　３５　サーバ
　１０１　送受信部
　１０２，４０２　鍵保持部
　１０３　判定部
　１０４　レベル情報保持部
　１１０，４１０　フレーム処理部
　１２０，４２０　フレーム生成部
　１３０，４３０　受信ＩＤ判断部
　１４０，４４０　受信ＩＤリスト保持部
　１５０，４５０　フレーム解釈部
　１６０，４６０　フレーム送受信部
　１８０　時刻情報取得部
　１９０　鍵更新確認部
　２００　ヘッドユニット
　３００　ゲートウェイ
　３１０　エンジン
　３２０　ブレーキ
　３３０　ドア開閉センサ
　３４０　窓開閉センサ
　３５０　エアバッグ
　４７０　データ取得部
　５００ａ～５００ｄ　バス
　６００　診断ポート
　８００　蓄電池

Claims (16)

  1. 　バスを介して通信を行う複数の電子制御ユニットを備え、外部ツールが接続される車載ネットワークシステムにおいて用いられる更新管理方法であって、
    　前記外部ツールの権限を示す更新権限情報を受信して検証し、
    　前記外部ツールから、１つ又は複数の前記電子制御ユニットが保持するデータの更新を指示する更新メッセージが送信された場合において、
    　前記検証が成功し、かつ、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージに対応して前記１つ又は複数の電子制御ユニットにより前記更新を実行し、
    　前記検証が失敗したとき、又は、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記１つ又は複数の電子制御ユニットによる前記更新メッセージに対応した前記更新を抑止する
    　更新管理方法。
  2. 　前記複数の電子制御ユニットは、Ｃｏｎｔｒｏｌｌｅｒ　Ａｒｅａ　Ｎｅｔｗｏｒｋ（ＣＡＮ）プロトコルに従って前記バスを介して通信を行い、
    　前記外部ツールは、ＣＡＮプロトコルに従って前記更新メッセージを送信する
    　請求項１記載の更新管理方法。
  3. 　前記外部ツールから前記更新メッセージが送信された場合において、当該更新メッセージのメッセージＩＤに基づいて、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示すか否かを判定し、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示すと判定したときには、前記メッセージＩＤを有する前記更新メッセージを受信するように定められている前記電子制御ユニットにより前記更新を実行する
    　請求項２記載の更新管理方法。
  4. 　前記更新権限情報は、前記電子制御ユニットの分類用の複数の機能種別のうち１つ又は複数の機能種別を特定し、特定した当該１つ又は複数の機能種別のいずれかに分類される前記電子制御ユニットに前記更新を行わせる権限を前記外部ツールが有することを表し、
    　前記外部ツールから前記更新メッセージが送信された場合において、当該更新メッセージのメッセージＩＤに基づいて、当該メッセージＩＤを受信するように定められている前記電子制御ユニットの機能種別が、前記更新権限情報により特定される１つ又は複数の機能種別のいずれかと一致するか否かを判別することにより、前記判定を行う
    　請求項３記載の更新管理方法。
  5. 　前記更新権限情報は、１つ又は複数の前記機能種別を特定するための複数のレベルのうち１つのレベルを示し、相対的に高いレベルは、相対的に低いレベルが特定する１つ又は複数の機能種別を包含した複数の機能種別を特定する
    　請求項４記載の更新管理方法。
  6. 　１つの前記電子制御ユニットである更新管理装置が、
    　当該更新管理装置と繋がった診断ポートに接続された前記外部ツールから前記更新権限情報を受信して前記検証を行い、
    　前記外部ツールから前記更新メッセージが送信された場合に当該更新メッセージを受信し、当該受信した場合において、前記検証が成功し、かつ、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージを前記バスに転送し、前記検証が失敗したとき、又は、当該更新メッセージの送信が当該外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記転送を抑止する
    　請求項１～５のいずれか一項に記載の更新管理方法。
  7. 　前記更新メッセージにセッション鍵を用いた所定暗号処理が施されていなければ当該更新メッセージに対応した前記電子制御ユニットによる前記更新を抑止し、
    　前記更新管理装置は、
    　前記更新権限情報の前記受信を、当該更新権限情報を記載した、前記外部ツールの公開鍵に係る公開鍵証明書の受信により行い、
    　前記検証に成功した場合に、前記外部ツールが前記更新メッセージの送信に際して当該更新メッセージに対して所定暗号処理を施すために用いる前記セッション鍵を、前記外部ツールの公開鍵で暗号化して前記外部ツールに送信する
    　請求項６記載の更新管理方法。
  8. 　前記更新管理装置は、前記外部ツールから前記更新メッセージが送信された場合において、前記車載ネットワークシステムを搭載する車両の状態が所定状態でないときには、前記更新メッセージの前記バスへの転送を抑止する
    　請求項６記載の更新管理方法。
  9. 　前記更新管理装置は、前記外部ツールから前記更新メッセージが送信された場合において、前記車載ネットワークシステムにおける各電子制御ユニットに電力を供給する電池が所定電池残量を有さないときには、前記更新メッセージの前記バスへの転送を抑止する
    　請求項６記載の更新管理方法。
  10. 　前記更新管理装置以外の電子制御ユニットと前記更新管理装置とは、通信内容に係る暗号処理用のセッション鍵の伝達に用いるために相互間で共有する共有鍵を保持し、
    　前記更新メッセージが指示する、前記電子制御ユニットが保持するデータの前記更新は、前記共有鍵の更新である
    　請求項６記載の更新管理方法。
  11. 　前記共有鍵の有効期限の一定期間前に前記共有鍵の更新を促す警告情報を出力する
    　請求項１０記載の更新管理方法。
  12. 　前記更新管理装置は、前記車載ネットワークシステムを、複数の車載ネットワークシステムの中で識別する識別情報と前記更新メッセージの処理結果を示す結果情報とを前記外部ツールに送信する
    　請求項６記載の更新管理方法。
  13. 　前記外部ツールは、前記結果情報と前記識別情報とをサーバに送信する
    　請求項１２記載の更新管理方法。
  14. 　前記更新メッセージが指示する、前記電子制御ユニットが保持するデータの前記更新は、前記電子制御ユニットのファームウェアの更新である
    　請求項１記載の更新管理方法。
  15. 　バスを介して通信を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて診断ポートと繋がった１つの電子制御ユニットである更新管理装置であって、
    　前記診断ポートに接続された外部ツールから前記診断ポートを介して送信される、当該外部ツールの権限を示す更新権限情報、及び、１つ又は複数の前記電子制御ユニットが保持するデータの更新を指示する更新メッセージを、受信する受信部と、
    　前記受信部により受信された前記更新権限情報を検証する検証部と、
    　前記受信部により前記更新メッセージが受信された場合において、前記検証部による前記検証が成功し、かつ、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージを前記バスに転送し、前記検証部による前記検証が失敗したとき、又は、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記転送を抑止する転送部とを備える
    　更新管理装置。
  16. 　バスを介して通信を行う複数の電子制御ユニットを備える車載ネットワークシステムにおいて診断ポートと繋がった１つの電子制御ユニットとしての、プロセッサを有する更新管理装置に、所定の更新管理処理を実行させるための制御プログラムであって、
    　前記更新管理処理は、
    　前記診断ポートに接続された外部ツールから前記診断ポートを介して送信される、当該外部ツールの権限を示す更新権限情報を受信する更新権限情報受信ステップと、
    　前記更新権限情報受信ステップにおいて受信された前記更新権限情報を検証する検証ステップと、
    　前記外部ツールから前記診断ポートを介して送信される、１つ又は複数の前記電子制御ユニットが保持するデータの更新を指示する更新メッセージを受信する更新メッセージ受信ステップと、
    　前記更新メッセージ受信ステップで前記更新メッセージが受信された場合において、前記検証ステップでの前記検証が成功し、かつ、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示すときには、前記更新メッセージを前記バスに転送し、前記検証ステップでの前記検証が失敗したとき、又は、当該更新メッセージの送信が前記外部ツールの権限範囲内であることを前記更新権限情報が示さないときには、前記転送を抑止する転送制御ステップとを含む
    　制御プログラム。
PCT/JP2015/005165 2014-11-12 2015-10-13 更新管理方法、更新管理装置及び制御プログラム WO2016075865A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
JP2016558862A JP6618480B2 (ja) 2014-11-12 2015-10-13 更新管理方法、更新管理システム及び制御プログラム
CN201910654690.5A CN110377310B (zh) 2014-11-12 2015-10-13 更新管理方法、更新管理装置以及计算机可读取的记录介质
EP15858625.5A EP3219553B1 (en) 2014-11-12 2015-10-13 Update management method, update management device, and control program
EP18186944.7A EP3412514B1 (en) 2014-11-12 2015-10-13 Update management method, update management device, and control program
CN201580027431.XA CN106458112B (zh) 2014-11-12 2015-10-13 更新管理方法、更新管理***以及计算机可读取的记录介质
US15/416,061 US10637657B2 (en) 2014-11-12 2017-01-26 Update management method, update management system, and non-transitory recording medium
US16/820,428 US11283601B2 (en) 2014-11-12 2020-03-16 Update management method, update management system, and non-transitory recording medium

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201462078476P 2014-11-12 2014-11-12
US62/078,476 2014-11-12
JP2015-187536 2015-09-24
JP2015187536 2015-09-24

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US15/416,061 Continuation US10637657B2 (en) 2014-11-12 2017-01-26 Update management method, update management system, and non-transitory recording medium

Publications (1)

Publication Number Publication Date
WO2016075865A1 true WO2016075865A1 (ja) 2016-05-19

Family

ID=55953972

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2015/005165 WO2016075865A1 (ja) 2014-11-12 2015-10-13 更新管理方法、更新管理装置及び制御プログラム

Country Status (5)

Country Link
US (2) US10637657B2 (ja)
EP (2) EP3412514B1 (ja)
JP (2) JP6618480B2 (ja)
CN (2) CN106458112B (ja)
WO (1) WO2016075865A1 (ja)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6279174B1 (ja) * 2017-02-28 2018-02-14 三菱電機株式会社 車両通信監視装置、車両通信監視方法および車両通信監視プログラム
CN108241514A (zh) * 2017-12-28 2018-07-03 宁德时代新能源科技股份有限公司 车载程序更新方法和装置
WO2019012888A1 (ja) * 2017-07-12 2019-01-17 住友電気工業株式会社 車載装置、管理方法および管理プログラム
JP2019075056A (ja) * 2017-10-19 2019-05-16 三菱電機株式会社 車両用セキュリティ装置およびセキュリティ方法
CN110275720A (zh) * 2018-03-16 2019-09-24 丰田自动车株式会社 程序更新管理装置
US10491392B2 (en) 2017-03-01 2019-11-26 Ford Global Technologies, Llc End-to-end vehicle secure ECU unlock in a semi-offline environment
EP3553684A4 (en) * 2016-12-09 2019-11-27 FeliCa Networks, Inc. INFORMATION PROCESSING DEVICE AND INFORMATION PROCESSING METHOD
KR20200020515A (ko) * 2018-08-17 2020-02-26 재단법인대구경북과학기술원 Can 시스템 및 메시지 인증 방법
JP2020086540A (ja) * 2018-11-15 2020-06-04 Kddi株式会社 メンテナンスサーバ装置、車両メンテナンスシステム、コンピュータプログラム及び車両メンテナンス方法
JP2020092289A (ja) * 2018-12-03 2020-06-11 大日本印刷株式会社 機器統合システム及び更新管理システム
JP2020132026A (ja) * 2019-02-22 2020-08-31 本田技研工業株式会社 ソフトウェア更新装置、車両及びソフトウェア更新方法
CN112083940A (zh) * 2020-07-29 2020-12-15 宁波三星医疗电气股份有限公司 基于国密算法的电力采集终端远程升级方法
EP3754935A1 (en) 2019-06-20 2020-12-23 Fujitsu Limited Key update device and storage medium storing key update program
WO2021005949A1 (ja) * 2019-07-05 2021-01-14 住友電気工業株式会社 中継装置および車両通信方法
US20220263849A1 (en) * 2020-01-14 2022-08-18 Panasonic Intellectual Property Corporation Of America Anomaly detection method, recording medium, and anomaly detection system

Families Citing this family (83)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6216730B2 (ja) * 2015-03-16 2017-10-18 日立オートモティブシステムズ株式会社 ソフト更新装置、ソフト更新方法
JP2016174243A (ja) * 2015-03-16 2016-09-29 カルソニックカンセイ株式会社 通信システム
JP6197000B2 (ja) * 2015-07-03 2017-09-13 Kddi株式会社 システム、車両及びソフトウェア配布処理方法
JP6281535B2 (ja) * 2015-07-23 2018-02-21 株式会社デンソー 中継装置、ｅｃｕ、及び、車載システム
EP3416052B1 (en) * 2016-02-11 2020-11-25 Hyundai Motor Company Method and device for wirelessly updating software for vehicle
JP6352325B2 (ja) * 2016-03-15 2018-07-04 本田技研工業株式会社 通信システム
CN109644153B (zh) * 2016-04-12 2020-10-13 伽德诺克斯信息技术有限公司 具有被配置为实现安全锁定的相关设备的特别编程的计算***及其使用方法
US10819418B2 (en) 2016-04-29 2020-10-27 Honeywell International Inc. Systems and methods for secure communications over broadband datalinks
US10171478B2 (en) * 2016-06-30 2019-01-01 Faraday & Future Inc. Efficient and secure method and apparatus for firmware update
US20180032421A1 (en) * 2016-07-29 2018-02-01 Wipro Limited Method and system for debugging automotive applications in an electronic control unit of an automobile
JP6665728B2 (ja) * 2016-08-05 2020-03-13 株式会社オートネットワーク技術研究所 車載更新装置、車載更新システム及び通信装置の更新方法
JP7037550B2 (ja) * 2016-09-23 2022-03-16 アップル インコーポレイテッド ネットワークトラフィックのセキュア通信
FR3057086B1 (fr) 2016-10-04 2018-11-23 Stmicroelectronics (Rousset) Sas Procede de gestion d'une mise a jour d'au moins un microcode au sein d'une unite de traitement, par exemple un microcontroleur, et unite de traitement correspondante
JP6696417B2 (ja) * 2016-12-20 2020-05-20 株式会社オートネットワーク技術研究所 車載更新装置、更新システム及び可搬型通信器
US20180212967A1 (en) * 2017-01-25 2018-07-26 NextEv USA, Inc. Portable device used to support secure lifecycle of connected devices
JP2018120422A (ja) * 2017-01-25 2018-08-02 ルネサスエレクトロニクス株式会社 車載通信システム、ドメインマスタ、及びファームウェア更新方法
JP6981755B2 (ja) * 2017-01-25 2021-12-17 トヨタ自動車株式会社 車載ネットワークシステム
DE112017006980T5 (de) * 2017-02-01 2019-10-17 Sumitomo Electric Industries, Ltd. Steuereinrichtung, Programmaktualisierungsverfahren und Computerprogramm
WO2018142504A1 (ja) * 2017-02-01 2018-08-09 富士通株式会社 暗号鍵配信システム、鍵配信ｅｃｕ、鍵受信ｅｃｕ、鍵配信プログラム、鍵受信プログラム及び暗号鍵配信方法
US10757113B2 (en) * 2017-03-17 2020-08-25 Cylance Inc. Communications bus signal fingerprinting
GB2561256A (en) * 2017-04-05 2018-10-10 Stmicroelectronics Grenoble2 Sas Apparatus for use in a can system
US10462193B2 (en) * 2017-06-07 2019-10-29 GM Global Technology Operations LLC Vehicle add-on multimedia playback and capture devices
JP7094670B2 (ja) * 2017-07-03 2022-07-04 矢崎総業株式会社 設定装置及びコンピュータ
CN111133412A (zh) 2017-07-25 2020-05-08 奥罗拉实验室有限公司 基于工具链构建车辆ecu软件的软件增量更新和异常检测
KR102368606B1 (ko) * 2017-07-31 2022-03-02 현대자동차주식회사 효율적인 차량용 리프로그래밍 장치 및 그 제어방법
US10904224B2 (en) * 2017-09-29 2021-01-26 Rolls-Royce Corporation Aircraft engine monitoring system
DE102017218872A1 (de) * 2017-10-23 2019-04-25 Robert Bosch Gmbh Verfahren und Vorrichtung zum Aktualisieren von Software eines Kfz-Steuergerätes
JP6915500B2 (ja) 2017-11-06 2021-08-04 トヨタ自動車株式会社 更新システム、電子制御装置、更新管理装置、及び更新管理方法
CN108073156B (zh) * 2017-11-20 2019-11-01 广州汽车集团股份有限公司 一种汽车电子控制单元的安全算法管理方法及***
US10009325B1 (en) * 2017-12-07 2018-06-26 Karamba Security End-to-end communication security
US10850684B2 (en) * 2017-12-19 2020-12-01 Micron Technology, Inc. Vehicle secure messages based on a vehicle private key
EP3531322A4 (en) 2017-12-28 2020-01-22 Shenzhen Launch Software Co., Ltd. METHOD AND DEVICE FOR CHECKING THE UPDATE OF A DIAGNOSTIC PLUG OF A DIAGNOSTIC DEVICE AND DIAGNOSTIC PLUG
US11178158B2 (en) * 2018-01-29 2021-11-16 Nagravision S.A. Secure communication between in-vehicle electronic control units
JP7010049B2 (ja) * 2018-02-16 2022-01-26 トヨタ自動車株式会社 車両制御装置、プログラムの更新確認方法および更新確認プログラム
JP7311245B2 (ja) * 2018-03-07 2023-07-19 トヨタ自動車株式会社 マスタ装置、マスタ、制御方法、プログラム及び車両
US11321466B2 (en) * 2018-03-09 2022-05-03 Qualcomm Incorporated Integrated circuit data protection
JP6950605B2 (ja) * 2018-03-27 2021-10-13 トヨタ自動車株式会社 車両用通信システム
US10819689B2 (en) 2018-05-03 2020-10-27 Honeywell International Inc. Systems and methods for encrypted vehicle data service exchanges
US10715511B2 (en) * 2018-05-03 2020-07-14 Honeywell International Inc. Systems and methods for a secure subscription based vehicle data service
CN110493002B (zh) 2018-06-25 2020-05-08 北京白山耘科技有限公司 一种证书续签的方法、装置及***
JP7111074B2 (ja) * 2018-08-10 2022-08-02 株式会社デンソー 車両用マスタ装置、セキュリティアクセス鍵の管理方法、セキュリティアクセス鍵の管理プログラム及び車両用電子制御システム
JP7439402B2 (ja) * 2018-08-10 2024-02-28 株式会社デンソー 表示制御装置、書換え進捗状況の表示制御方法及び書換え進捗状況の表示制御プログラム
JP7059985B2 (ja) * 2018-08-10 2022-04-26 株式会社デンソー 車両用電子制御システム、車両用マスタ装置、データ格納面情報の送信制御方法、データ格納面情報の送信制御プログラム、車両用マスタ装置側プログラム、センター装置、更新データの選定方法及びセンター装置側プログラム
KR102523250B1 (ko) 2018-09-20 2023-04-20 현대자동차주식회사 차량용 제어 장치, 차량, 및 차량의 제어방법
US10931476B2 (en) * 2018-10-29 2021-02-23 Analog Devices Global Unlimited Company Content protection over synchronous data networks
JP7132132B2 (ja) * 2019-01-09 2022-09-06 国立大学法人東海国立大学機構 車載通信システム、車載通信制御装置、車載通信装置、コンピュータプログラム、通信制御方法及び通信方法
FR3092684B1 (fr) * 2019-02-11 2021-01-15 Psa Automobiles Sa Procédé et dispositif de mise à jour d’une unité de commande électronique
CN110001553B (zh) * 2019-02-25 2021-07-09 南京航空航天大学 一种汽车四向可调转向操纵装置、控制器下载方法
JP7111030B2 (ja) * 2019-03-04 2022-08-02 株式会社オートネットワーク技術研究所 車載更新装置、更新処理プログラム及び、プログラムの更新方法
CN110138642B (zh) * 2019-04-15 2021-09-07 深圳市纽创信安科技开发有限公司 一种基于can总线的安全通信方法和***
KR20200131639A (ko) * 2019-05-14 2020-11-24 현대자동차주식회사 게이트웨이 장치 및 그 제어방법
WO2020240984A1 (ja) * 2019-05-30 2020-12-03 住友電気工業株式会社 設定装置、通信システムおよび車両通信管理方法
CN110290002B (zh) * 2019-06-27 2023-08-01 北京百度网讯科技有限公司 一种更新方法、终端及电子设备
CN110324335B (zh) * 2019-07-02 2020-04-28 成都信息工程大学 一种基于电子移动证书的汽车软件升级方法及***
CN112602287B (zh) * 2019-07-19 2022-02-11 华为技术有限公司 Can通信方法、设备及***
WO2021039622A1 (ja) * 2019-08-30 2021-03-04 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 認証方法、認証システム及び認証装置
US20210075783A1 (en) * 2019-09-10 2021-03-11 William Mazzara, JR. Authenticated vehicle diagnostic access techniques
CN114651456A (zh) 2019-09-20 2022-06-21 桑纳特斯公司 用于交通工具外通信控制的***、方法和装置
TWI716135B (zh) * 2019-10-04 2021-01-11 財團法人資訊工業策進會 用於車用網路之安全監控裝置及方法
JP7502014B2 (ja) * 2019-10-31 2024-06-18 トヨタ自動車株式会社 車両用制御装置、プログラム更新方法、及びプログラム更新システム
JP7220397B2 (ja) * 2019-12-09 2023-02-10 パナソニックＩｐマネジメント株式会社 情報処理装置および情報処理方法
CN114884737A (zh) * 2019-12-23 2022-08-09 华为技术有限公司 通信方法及相关产品
CN113132092B (zh) * 2019-12-31 2022-04-22 华为技术有限公司 通信方法和电子设备
CN113138591B (zh) * 2020-01-20 2022-12-23 北京新能源汽车股份有限公司 一种车辆安全因子的控制方法、装置、控制设备及汽车
JP7342734B2 (ja) 2020-03-03 2023-09-12 株式会社デンソー 車両データ管理装置、車両データ管理システム、車両データ管理方法、車両データ管理プログラム
US20230161583A1 (en) * 2020-03-06 2023-05-25 Sonatus, Inc. System, method, and apparatus for managing vehicle automation
US20230158975A1 (en) * 2020-03-06 2023-05-25 Sonatus, Inc. System, method, and apparatus for managing vehicle automation
EP3913880A1 (en) 2020-05-19 2021-11-24 Continental Teves AG & Co. OHG Method of and system for secure data export from an automotive engine control unit
US11871228B2 (en) * 2020-06-15 2024-01-09 Toyota Motor Engineering & Manufacturing North America, Inc. System and method of manufacturer-approved access to vehicle sensor data by mobile application
US11880670B2 (en) 2020-06-23 2024-01-23 Toyota Motor North America, Inc. Execution of transport software update
US11281450B2 (en) 2020-06-23 2022-03-22 Toyota Motor North America, Inc. Secure transport software update
WO2022004447A1 (ja) * 2020-07-03 2022-01-06 ソニーグループ株式会社 情報処理装置、および情報処理方法、情報処理システム、並びにプログラム
CN111942154B (zh) * 2020-07-28 2022-03-08 广汽埃安新能源汽车有限公司 一种用于电池管理***的唤醒装置、车辆
US20220085984A1 (en) * 2020-09-14 2022-03-17 Amir Keyvan Khandani Methods and apparatus for randomized encryption, with an associated randomized decryption
CN114384887B (zh) * 2020-10-16 2024-07-19 长城汽车股份有限公司 一种排放诊断方法、装置与电子设备
KR102427977B1 (ko) * 2020-11-13 2022-08-01 경희대학교 산학협력단 추가 하드웨어 모듈을 이용하는 자동차 ecu 업데이트 방법
JP7380530B2 (ja) * 2020-11-13 2023-11-15 トヨタ自動車株式会社 車両通信システム、通信方法及び通信プログラム
CN112506562B (zh) * 2020-12-29 2023-09-26 一汽解放汽车有限公司 车辆软件升级方法、***、车辆及存储介质
CN112698844A (zh) * 2020-12-29 2021-04-23 威海新北洋技术服务有限公司 操作***的刷机方法、装置及电子设备
JP7447864B2 (ja) * 2021-04-26 2024-03-12 トヨタ自動車株式会社 Ｏｔａマスタ、方法およびプログラム
CN113259933B (zh) * 2021-06-15 2023-08-29 北京天融信网络安全技术有限公司 一种密钥更新的方法、网关、控制装置、电子设备及介质
KR20230025131A (ko) * 2021-08-13 2023-02-21 주식회사 엘지에너지솔루션 배터리 데이터 관리 시스템 및 그것의 동작 방법
US20230153094A1 (en) * 2021-11-18 2023-05-18 Toyota Motor North America, Inc. Robust over the air reprogramming

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009147734A1 (ja) * 2008-06-04 2009-12-10 株式会社ルネサステクノロジ 車両、メンテナンス装置、メンテナンスサービスシステム及びメンテナンスサービス方法
JP2012103181A (ja) * 2010-11-12 2012-05-31 Clarion Co Ltd 車載機のオンライン更新方法
JP2012188027A (ja) * 2011-03-11 2012-10-04 Omron Automotive Electronics Co Ltd 情報処理装置、情報処理方法、およびプログラム
JP2013141948A (ja) * 2012-01-12 2013-07-22 Denso Corp 車両通信システム
JP2014168219A (ja) * 2013-01-31 2014-09-11 Auto Network Gijutsu Kenkyusho:Kk アクセス制限装置、車載通信システム及び通信制限方法

Family Cites Families (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19623145B4 (de) * 1996-06-10 2004-05-13 Robert Bosch Gmbh Verfahren zum Betreiben eines Steuergerätes mit einer über eine Programmiervorrichtung programmierbaren Speichereinrichtung
JP3913823B2 (ja) * 1997-02-10 2007-05-09 株式会社東海理化電機製作所 車両用始動許可装置
US8325994B2 (en) * 1999-04-30 2012-12-04 Davida George I System and method for authenticated and privacy preserving biometric identification systems
JP2001225706A (ja) * 1999-12-07 2001-08-21 Denso Corp 電子制御装置の制御情報書換システム、当該システムに用いられるセンタ、電子制御装置、及び書換装置
US7068147B2 (en) 1999-12-07 2006-06-27 Denso Corporation Control information rewriting system
DE10008974B4 (de) * 2000-02-25 2005-12-29 Bayerische Motoren Werke Ag Signaturverfahren
JP4426733B2 (ja) * 2000-03-31 2010-03-03 富士通株式会社 指紋データ合成方法，指紋データ合成装置，指紋データ合成プログラムおよび同プログラムを記録したコンピュータ読取可能な記録媒体
JP2002144983A (ja) 2000-11-14 2002-05-22 Toyoda Mach Works Ltd 車両制御装置の制御ソフト変更装置及びその方法
JP2003343133A (ja) * 2002-03-20 2003-12-03 Matsushita Electric Ind Co Ltd デジタル鍵システムと装置
JP2004028000A (ja) 2002-06-27 2004-01-29 Mitsubishi Electric Corp 通信による車載ｅｃｕのメモリ書き換え装置
EP1590917B1 (en) * 2003-01-28 2010-12-15 Cellport Systems, Inc. A system and a method for controlling use by applications of proprietary resources within a secure telematics system in a vehicle
US8842887B2 (en) * 2004-06-14 2014-09-23 Rodney Beatson Method and system for combining a PIN and a biometric sample to provide template encryption and a trusted stand-alone computing device
US8375218B2 (en) * 2004-12-07 2013-02-12 Mitsubishi Electric Research Laboratories, Inc. Pre-processing biometric parameters before encoding and decoding
WO2006129654A1 (ja) * 2005-06-01 2006-12-07 Matsushita Electric Industrial Co., Ltd. 電子機器、更新サーバ装置、鍵更新装置
US20080072068A1 (en) * 2006-09-19 2008-03-20 Wang Liang-Yun Methods and apparatuses for securing firmware image download and storage by distribution protection
JP2008239021A (ja) * 2007-03-28 2008-10-09 Denso Corp 車両制御装置及びそのデータ書換システム
DE102007039602A1 (de) * 2007-08-22 2009-02-26 Siemens Ag Verfahren zum Prüfen einer auf einer ersten Einrichtung auszuführenden oder zu installierenden Version eines Softwareproduktes
US8484752B2 (en) * 2007-11-14 2013-07-09 Caterpillar Inc. Verifying authenticity of electronic control unit code
CA2946778A1 (en) * 2008-02-22 2009-08-27 Security First Corp. Systems and methods for secure workgroup management and communication
US8838990B2 (en) * 2008-04-25 2014-09-16 University Of Colorado Board Of Regents Bio-cryptography: secure cryptographic protocols with bipartite biotokens
JP5248930B2 (ja) * 2008-06-12 2013-07-31 株式会社東海理化電機製作所 暗号通信システム及び暗号鍵更新方法
US8127124B2 (en) * 2009-03-19 2012-02-28 Hewlett-Packard Development Company, L.P. Remote configuration of computing platforms
JP4931957B2 (ja) 2009-04-23 2012-05-16 本田技研工業株式会社 車両機能管理システム
JP2010271952A (ja) * 2009-05-21 2010-12-02 Toshiba Corp 分散型制御システムのデータ管理装置
CN102549617B (zh) * 2009-10-05 2014-10-08 富士通株式会社 生物体信息处理装置、生物体信息处理方法以及生物体信息处理用计算机程序
JP5218366B2 (ja) 2009-10-07 2013-06-26 トヨタ自動車株式会社 車両用プログラム更新装置
KR101030910B1 (ko) * 2009-10-19 2011-04-22 에스비리모티브 주식회사 배터리 관리 시스템 및 그 구동 방법
US9464905B2 (en) * 2010-06-25 2016-10-11 Toyota Motor Engineering & Manufacturing North America, Inc. Over-the-air vehicle systems updating and associate security protocols
WO2012139919A2 (en) * 2011-04-09 2012-10-18 Universität Zürich Method and apparatus for public-key cryptography based on error correcting codes
JP5605294B2 (ja) * 2011-04-15 2014-10-15 トヨタ自動車株式会社 認証システム及び認証方法
JP2013048374A (ja) * 2011-08-29 2013-03-07 Toyota Motor Corp 保護通信方法
JP2013137729A (ja) 2011-11-29 2013-07-11 Auto Network Gijutsu Kenkyusho:Kk プログラム書換システム、制御装置、プログラム配信装置、識別情報記憶装置、及びプログラム書換方法
JP5435022B2 (ja) * 2011-12-28 2014-03-05 株式会社デンソー 車載システム及び通信方法
CN102662692B (zh) * 2012-03-16 2015-05-27 北京经纬恒润科技有限公司 一种电子控制单元中应用程序的更新方法及***
KR101974136B1 (ko) * 2012-09-10 2019-04-30 삼성전자주식회사 차량의 정보를 처리하는 시스템 및 방법
US20140372766A1 (en) * 2013-06-14 2014-12-18 Pitney Bowes Inc. Automated document notarization
US9288048B2 (en) * 2013-09-24 2016-03-15 The Regents Of The University Of Michigan Real-time frame authentication using ID anonymization in automotive networks
JP6126980B2 (ja) * 2013-12-12 2017-05-10 日立オートモティブシステムズ株式会社 ネットワーク装置およびネットワークシステム
KR20150074414A (ko) * 2013-12-24 2015-07-02 현대자동차주식회사 펌웨어 업그레이드 방법 및 그 시스템
EP2892200B1 (en) 2014-01-06 2021-11-03 Argus Cyber Security Ltd Bus watchman
KR101450166B1 (ko) * 2014-01-23 2014-10-13 현대자동차주식회사 차량 내 통신 네트워크에서의 라우팅 정보 갱신 방법 및 그 장치
US9231936B1 (en) * 2014-02-12 2016-01-05 Symantec Corporation Control area network authentication
US9229704B2 (en) * 2014-04-01 2016-01-05 Ford Global Technologies, Llc Smart vehicle reflash with battery state of charge (SOC) estimator
US9460567B2 (en) * 2014-07-29 2016-10-04 GM Global Technology Operations LLC Establishing secure communication for vehicle diagnostic data
US9684908B2 (en) * 2014-08-01 2017-06-20 Yahoo!, Inc. Automatically generated comparison polls

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009147734A1 (ja) * 2008-06-04 2009-12-10 株式会社ルネサステクノロジ 車両、メンテナンス装置、メンテナンスサービスシステム及びメンテナンスサービス方法
JP2012103181A (ja) * 2010-11-12 2012-05-31 Clarion Co Ltd 車載機のオンライン更新方法
JP2012188027A (ja) * 2011-03-11 2012-10-04 Omron Automotive Electronics Co Ltd 情報処理装置、情報処理方法、およびプログラム
JP2013141948A (ja) * 2012-01-12 2013-07-22 Denso Corp 車両通信システム
JP2014168219A (ja) * 2013-01-31 2014-09-11 Auto Network Gijutsu Kenkyusho:Kk アクセス制限装置、車載通信システム及び通信制限方法

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11159521B2 (en) 2016-12-09 2021-10-26 Felica Networks, Inc. Information processing apparatus and information processing method
EP3553684A4 (en) * 2016-12-09 2019-11-27 FeliCa Networks, Inc. INFORMATION PROCESSING DEVICE AND INFORMATION PROCESSING METHOD
JP6279174B1 (ja) * 2017-02-28 2018-02-14 三菱電機株式会社 車両通信監視装置、車両通信監視方法および車両通信監視プログラム
WO2018158848A1 (ja) * 2017-02-28 2018-09-07 三菱電機株式会社 車両通信監視装置、車両通信監視方法および車両通信監視プログラム
US10491392B2 (en) 2017-03-01 2019-11-26 Ford Global Technologies, Llc End-to-end vehicle secure ECU unlock in a semi-offline environment
WO2019012888A1 (ja) * 2017-07-12 2019-01-17 住友電気工業株式会社 車載装置、管理方法および管理プログラム
JP2019021973A (ja) * 2017-07-12 2019-02-07 住友電気工業株式会社 車載装置、管理方法および管理プログラム
US11938897B2 (en) 2017-07-12 2024-03-26 Sumitomo Electric Industries, Ltd. On-vehicle device, management method, and management program
CN110892683A (zh) * 2017-07-12 2020-03-17 住友电气工业株式会社 车载装置、管理方法和管理程序
JP2019075056A (ja) * 2017-10-19 2019-05-16 三菱電機株式会社 車両用セキュリティ装置およびセキュリティ方法
CN108241514A (zh) * 2017-12-28 2018-07-03 宁德时代新能源科技股份有限公司 车载程序更新方法和装置
CN110275720A (zh) * 2018-03-16 2019-09-24 丰田自动车株式会社 程序更新管理装置
KR102148453B1 (ko) 2018-08-17 2020-08-27 재단법인대구경북과학기술원 Can 시스템 및 메시지 인증 방법
KR20200020515A (ko) * 2018-08-17 2020-02-26 재단법인대구경북과학기술원 Can 시스템 및 메시지 인증 방법
JP2020086540A (ja) * 2018-11-15 2020-06-04 Kddi株式会社 メンテナンスサーバ装置、車両メンテナンスシステム、コンピュータプログラム及び車両メンテナンス方法
JP2020092289A (ja) * 2018-12-03 2020-06-11 大日本印刷株式会社 機器統合システム及び更新管理システム
JP7143744B2 (ja) 2018-12-03 2022-09-29 大日本印刷株式会社 機器統合システム及び更新管理システム
US11099830B2 (en) 2019-02-22 2021-08-24 Honda Motor Co., Ltd. Software updating apparatus, vehicle, and software updating method
JP2020132026A (ja) * 2019-02-22 2020-08-31 本田技研工業株式会社 ソフトウェア更新装置、車両及びソフトウェア更新方法
EP3754935A1 (en) 2019-06-20 2020-12-23 Fujitsu Limited Key update device and storage medium storing key update program
WO2021005949A1 (ja) * 2019-07-05 2021-01-14 住友電気工業株式会社 中継装置および車両通信方法
JP7476896B2 (ja) 2019-07-05 2024-05-01 住友電気工業株式会社 中継装置、車両通信方法および車両通信プログラム
US20220263849A1 (en) * 2020-01-14 2022-08-18 Panasonic Intellectual Property Corporation Of America Anomaly detection method, recording medium, and anomaly detection system
CN112083940A (zh) * 2020-07-29 2020-12-15 宁波三星医疗电气股份有限公司 基于国密算法的电力采集终端远程升级方法
CN112083940B (zh) * 2020-07-29 2023-03-03 宁波三星医疗电气股份有限公司 基于国密算法的电力采集终端远程升级方法

Also Published As

Publication number Publication date
US20200220716A1 (en) 2020-07-09
JP2022163096A (ja) 2022-10-25
JP6618480B2 (ja) 2019-12-11
CN106458112A (zh) 2017-02-22
CN110377310B (zh) 2023-04-07
EP3219553A1 (en) 2017-09-20
CN110377310A (zh) 2019-10-25
JP7334312B2 (ja) 2023-08-28
EP3412514B1 (en) 2019-12-04
US20170134164A1 (en) 2017-05-11
US11283601B2 (en) 2022-03-22
EP3412514A1 (en) 2018-12-12
EP3219553A4 (en) 2017-10-25
EP3219553B1 (en) 2019-01-23
CN106458112B (zh) 2019-08-13
US10637657B2 (en) 2020-04-28
JPWO2016075865A1 (ja) 2017-10-19

Similar Documents

Publication Publication Date Title
JP7334312B2 (ja) 更新管理方法、更新管理装置及び制御プログラム
JP6873198B2 (ja) 不正検知ルール更新方法、不正検知電子制御ユニット及び車載ネットワークシステム
JP6713415B2 (ja) 鍵管理方法、車載ネットワークシステム及び鍵管理装置
JP7116204B2 (ja) 更新管理方法、更新管理装置及び制御プログラム
EP3403246B1 (en) A device and method for collecting user-based insurance data in vehicles
US20130212659A1 (en) Trusted connected vehicle systems and methods
US20130173112A1 (en) In-vehicle system and communication method
WO2009147734A1 (ja) 車両、メンテナンス装置、メンテナンスサービスシステム及びメンテナンスサービス方法
WO2017115751A1 (ja) 車載コンピュータシステム、車両、管理方法、及びコンピュータプログラム
JP7412506B2 (ja) 不正検知ルール更新方法、不正検知電子制御ユニット及び車載ネットワークシステム
JP6260068B1 (ja) 保守装置、保守方法、及びコンピュータプログラム
KR102436138B1 (ko) 차량용 이더넷 기반 차량 내부 네트워크를 이용한 차량 부품 교체 방법 및 시스템
Ammar et al. Securing the on-board diagnostics port (obd-ii) in vehicles
KR20150089697A (ko) 모바일 단말을 이용한 스마트 카 보안 시스템 및 그 방법
CN118018280A (zh) 用于车辆数据传输的方法、装置、车辆和存储介质
Daimi A Security Architecture for Remote Diagnosis of Vehicle Defects

Legal Events

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

Ref document number: 15858625

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2016558862

Country of ref document: JP

Kind code of ref document: A

REEP Request for entry into the european phase

Ref document number: 2015858625

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2015858625

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE