Patent Description:
In recent years, a great number of electronic control units (ECU) have been placed in systems in automobiles. A network connecting these ECUs is referred to as an onboard network. Many standards exist for onboard networks. The most mainstream of these is a standard called CAN (Controller Area Network), that is stipulated in ISO11898-<NUM> (see "NPL <NUM>").

A CAN is configured using two busses, and each ECU connected to the buses is called a node. Each node connected to a bus transmits/receives messages called frames. No identifiers indicating the transmission destination or transmission source exist in CAN, with the transmitting node attaching an ID (called CAN-ID) to each frame and transmitting (i.e., sending out signals to the bus), and the receiving nodes only receiving frames of a predetermined ID (i.e., reading signals from the bus). The CSMA/CA (Carrier Sense Multiple Access / Collision Avoidance) format is employed, so when multiple nodes transmit at the same time, arbitration by CAN-ID is performed, with frames having a smaller message ID value being transmitted with higher priority.

Now, CAN does not have a security function assuming a case where unauthorized frames are transmitted, so there is a possibility that the vehicle might be unauthorizedly controlled by an unauthorized node being connected to the bus in the onboard network and the unauthorized frame unauthorizedly transmitting a frame. There is known a technology in CAN where frames transmitted by authorized ECUs are identified by adding a message authentication code (MAC) to the data field and transmitting, in order to prevent control by such unauthorized frames (see "PTL <NUM>"). A temporary session key is preferably periodically generated and used in generating MACs, to improve resistance against brute-force attacks against MACs to try to identify the key to generate MACs.

Now, in a case where a particular ECU handles generating of a session key, the session key can be safety distributed (transmitted) among ECUs if the session keys are encrypted using a key shared among authorized ECUs beforehand (called a "shared key").

However, if leakage of the shared key cannot be appropriately detected, this enables an unauthorized ECU to receive the session key and generate MACs.

Accordingly, the present disclosure provides a key management method for securing security of an onboard network having multiple ECUs storing a shared key. The present disclosure also provides an onboard network system and key management device for securing security in communication among ECUs storing a shared key.

A key management method according to an aspect of the present disclosure to solve the above problem is a key management method in an onboard network system having a plurality of electronic control units that perform communication by frames via a bus. The method includes a first-type electronic control unit, out of the plurality of electronic control units, storing a shared key to be mutually shared with one or more second-type electronic control units other than the first -type electronic control unit; each of the second-type electronic control units acquiring a session key by communication with the first-type electronic control unit based on the stored shared key, and after this acquisition, executing encryption processing regarding a frame transmitted or received via the bus, using this session key; and the first-type electronic control unit executing inspection of a security state of the shared key stored by the second-type electronic control units in a case where a vehicle in which the onboard network system is installed is in a particular state.

An onboard network system according to an aspect of the present disclosure to solve the above problem is an onboard network system having a plurality of electronic control units that perform communication by frames via a bus. A first-type electronic control unit, out of the plurality of electronic control units, stores a shared key to be mutually shared with one or more second-type electronic control units other than the first -type electronic control unit, each of the second-type electronic control units acquire a session key by communication with the first-type electronic control unit based on the stored shared key, and after this acquisition, execute encryption processing regarding a frame transmitted or received via the bus, using this session key, and the first-type electronic control unit executes inspection of a security state of the shared key stored by the second-type electronic control units in a case where a vehicle in which itself is installed is in a particular state.

A key management device according to an aspect of the present disclosure to solve the above problem is a key management device serving as an electronic control unit in an onboard network system having a plurality of electronic control units that perform communication by frames via a bus. The key management device stores a shared key to be mutually shared with one or more electronic control units other than itself out of the plurality of electronic control units, for transmission of a session key used for encryption relating to a frame, and the key management device executes inspection of a security state of the shared key stored by the electronic control units other than itself in a case where a vehicle in which itself is installed is in a particular state.

According to the present disclosure, the security state of the shared key is inspected on a timely basis, so security of the onboard network system can be secured.

A key management method according to an aspect of the present disclosure is a key management method in an onboard network system having a plurality of electronic control units that perform communication by frames via a bus. The method includes a first-type electronic control unit, out of the plurality of electronic control units, storing a shared key to be mutually shared with one or more second-type electronic control units other than the first -type electronic control unit; each of the second-type electronic control units acquiring a session key by communication with the first-type electronic control unit based on the stored shared key, and after this acquisition, executing encryption processing regarding a frame transmitted or received via the bus, using this session key; and the first-type electronic control unit executing inspection of a security state of the shared key stored by the second-type electronic control units in a case where a vehicle in which the onboard network system is installed is in a particular state. Thus, security of the onboard network system can be secured.

The inspection may be an inspection relating to an expiration date of the shared key. Accordingly, expiration of the shared key can be detected, and acquisition of session keys by an unauthorized ECU having an expired shared key can be prevented.

The first-type electronic control unit may receive, from the second-type electronic control unit, a frame including information indicating the expiration date regarding the shared key that the second-type electronic control unit holds, perform the inspection by distinguishing whether or not the expiration date has already expired, an in a case where the expiration date has not expired, perform communication to give the second-type electronic control unit a session key, but in a case where the expiration date has expired, execute control for notification. Accordingly, notification is made in a case where the security state of the shared key is inappropriate due to the existence of an ECU having an expired shared key, so security can be secured.

The inspection may be an inspection relating to a serial ID of the second-type electronic control unit that stores the shared key. Accordingly, the existence of an unauthorized ECU that has unauthorizedly copied (duplicated) the share key can be detected, and acquisition of a session key by the unauthorized ECU can be prevented.

The first-type electronic control unit may receive, from the second-type electronic control unit, a frame including information indicating the serial ID of the second-type electronic control unit, perform the inspection by distinguishing whether or not the security state of the shared key is appropriate based on the serial ID and predetermined matching information stored beforehand, and in a case where the security state of the shared key is appropriate, performs communication to give the second-type electronic control unit a session key, but in a case where the security state of the shared key is not appropriate, execute control for notification. Accordingly, notification is made in a case where the security state of the shared key is inappropriate due to the existence of the ECU having an unauthorized serial ID, so security can be secured.

In a case where the plurality of electronic control units includes a plurality of the second-type electronic control units, the inspection may be an inspection relating to a transmission order of frames at the plurality of second-type electronic control units. Accordingly, inappropriate transmission order of frames among the ECUs can be detected, and acquisition of a session key by an unauthorized ECU can be prevented.

The first-type electronic control unit may transmit a frame indicating a predetermined request and thereafter sequentially receive frames from the plurality of second-type electronic control units, and based on the IDs of the frames, perform the inspection by distinguishing whether or not the IDs have been received in an order that a predetermined order list indicates. Accordingly, whether or not an unauthorized ECU exists can be detected from the order of responses from each ECU after having transmitted a frame (survival confirmation frame or the like) indicating a predetermined request.

The particular state may be a state where the vehicle is not driving, with the first-type electronic control unit executing the inspection only in a case of the particular state. Accordingly, inspection of the security state can be appropriately performed while avoiding increased processing load on the ECUs increased traffic on the bus and so forth while the vehicle is driving.

The first-type electronic control unit may execute the inspection by communication with a server located externally from the vehicle. Accordingly, the load of the inspection of the security state within the onboard network system can be reduced. Also, inspections using information collected externally from the vehicle (information obtained from other onboard network systems and so forth) may also be performed.

The plurality of electronic control units may perform communication by frames via the bus, following a CAN (Controller Area Network) protocol. Accordingly, security can be secured in a onboard network system following CAN.

An onboard network system according to an aspect of the present disclosure is an onboard network system having a plurality of electronic control units that perform communication by frames via a bus. A first-type electronic control unit, out of the plurality of electronic control units, stores a shared key to be mutually shared with one or more second-type electronic control units other than the first -type electronic control unit, each of the second-type electronic control units acquire a session key by communication with the first-type electronic control unit based on the stored shared key, and after this acquisition, execute encryption processing regarding a frame transmitted or received via the bus, using this session key, and the first-type electronic control unit executes inspection of a security state of the shared key stored by the second-type electronic control units in a case where a vehicle in which itself is installed is in a particular state. Thus, security of the onboard network system can be secured.

A key management device according to an aspect of the present disclosure is a key management device serving as an electronic control unit in an onboard network system having a plurality of electronic control units that perform communication by frames via a bus. The key management device stores a shared key to be mutually shared with one or more electronic control units other than itself out of the plurality of electronic control units, for transmission of a session key used for encryption relating to a frame, and the key management device executes inspection of a security state of the shared key stored by the electronic control units other than itself in a case where a vehicle in which Itself is installed is in a particular state. Thus, security of the onboard network system can be secured.

These general or specific aspects may be realized by a system, method, integrated circuit, computer program, or computer-readable recording medium such as a CD-ROM, and may be realized by any combination of a system, method, integrated circuit, computer program, and recording medium.

The following is a detailed description of an onboard network system according to embodiments with reference to the drawings. Note that the embodiments described below are all specific examples of the present disclosure. Accordingly, values, components, placements and connected states of components, steps (processes) and the order of steps, and so forth illustrated in the following embodiments, are only exemplary, and do not restrict the present disclosure. Components in the following embodiments which are not included in an independent Claim are optional components. The drawings are all schematic diagrams and are not necessarily created in an exact manner.

A key management method used in an onboard network system <NUM> in which multiple ECUs including a master ECU (key managing device) <NUM> communicate via a bus will be described below with reference to the drawings.

An example will be described in the present embodiment regarding a key management method, where whether or not the risk of leaking of a shared key, which each ECU stores, has increased (i.e., whether or not the state is one where updating of the shared key is necessary) is determined (verified) regarding security, based on an expiration data of the shared key, in accordance with the state of the vehicle.

<FIG> is a diagram illustrating the overall configuration of the onboard network system <NUM> according to a first embodiment. The onboard network system <NUM> is an example of a network communication system that communicates following the CAN protocol, and is a network communication system in an automobile in which is installed various types of devices such as control devices, sensors, and so forth. The onboard network system <NUM> has multiple devices that communicate by frames via a bus following the CAN protocol, and uses a key management method. Specifically, the onboard network system <NUM> is configured including a bus <NUM>, the master ECU (key management device) <NUM>, and nodes like ECUs connected to the bus, such as ECUs 100a through 100d and so forth, that are connected to various types of devices, as illustrated in <FIG>. The onboard network system <NUM> may include many more ECUs than the master ECU <NUM> and ECUs 100a through 100d, but description will be made here focusing on the master ECU <NUM> and ECUs 100a through 100d for sake of convenience. An ECU is a device that includes, for example, digital circuits such as a processor (microprocessor), memory, and so forth, analog circuits, communication circuits, and so forth. The memory is ROM, RAM, and so forth, capable of storing a control program (computer program) to be executed by the processor. The ECU can realize various functions by the processor operating following the control program (computer program), for example. The computer program is configured as a combination of multiple command codes representing instructions to the processor, to achieve predetermined functions.

The ECUs 100a through 100d are connected to the bus <NUM>, and are connected to an engine <NUM>, brakes <NUM>, a door open/closed sensor <NUM>, and a window opened/closed sensor <NUM>, respectively. Each of the ECUs 100a through 100d acquires the state of the device to which it is connected (engine <NUM>, etc.), and periodically transmits frames (later-described data frames) and so forth representing the state to the network (i.e., the bus).

There is one master ECU <NUM> connected to the bus <NUM>, as a type of ECU serving as a key managing device that has the role of handling processing relating to keys used in exchanging frames among the ECUs. The master ECU <NUM> has the same shared key as one or more ECUs out of the multiple ECUs connected to the bus <NUM> besides itself, to use for transmitting session keys mutually between the one or more ECUs for encryption processing relating to frames (including MAC processing), and functions to manage the security state of the shared key. The master ECU <NUM> may record a log of the security state of the shared key in a recording medium such as memory, a hard disk, or the like, as necessary. The master ECU <NUM> may have a display device such as a liquid crystal device (LCD) or the like provided on an instrument panel or the like of the automobile, so as to notify the driver by displaying information according to the security state of the shared key.

The ECUs on the onboard network system <NUM> including the master ECU <NUM> exchange frames following the CAN protocol. Frames in the CAN protocol include data frames, remote frames overload frames, and error frames. Description will be made primarily here regarding data frames, for sake of convenience.

The following is a description of a data frame which is a type of frame used on a network according to the CAN protocol.

<FIG> is a diagram illustrating a format of a data frame stipulated by the CAN protocol. The diagram illustrates a data frame according to a standard ID format stipulated in the CAN protocol. A data frame is configured including the fields of a SOF (Start Of Frame). ID field, RTR (Remote Transmission Request), IDE (Identifier Extension), reserved bit "r", DLC (Data Length Code), data field, CRC (Cyclic Redundancy Check) sequence, CRC delimiter "DEL", ACK (Acknowledgement) slot, ACK delimiter "DEL", and EOF (End Of Frame).

The SOF is made up of <NUM>-bit dominant. The state of the bus is recessive when idle, and start of transmission of a frame is notified by being changed to dominant by the SOF.

The ID field is made up of <NUM> bits, and is a field storing an ID (CAN-ID) which is a value indicating the type of data. Design has been implemented so that in a case where multiple nodes start transmission at the same time, frames with smaller ID values are given higher priority, in order to perform communication arbitration using this ID field.

The RTR is a value identifying a data frame and remote frame, and is made up of <NUM>-bit dominant in a data frame.

The IDE and "r" are each made up of <NUM>-bit dominant.

The DLC is made up of four bits, and is a value indicating the length of the data field. Note that the IDE, "r", and DLC together are called a control field.

The data field is a maximum of <NUM> bits, and is a value indicating the content of the data being transmitted. The length can be adjusted in <NUM>-bit increments. The CAN protocol does not stipulate the specification of data being transmitted; that is set at the onboard network system <NUM>. Accordingly, the specification is dependent on the model, manufacturer (manufacturing maker), or the like.

The CRC sequence ("CRC" illustrated in <FIG>) is made up of <NUM> bits. This is calculated from the transmitted values of the SOF, ID field, control field, and data field.

The CRC delimiter (the "DEL" between the "CRC" and "ACK" in <FIG>) is made up of <NUM>-bit recessive, and is a sectioning symbol representing the end of the CRC sequence. The CRC sequence and CRC delimiter are collectively referred to as the CRC field.

The ACK slot (the "ACK" in <FIG>) is made up of one bit. The transmitting node performs transmission with the ACK slot set to recessive. The receiving node transmits the ACK slot as dominant if up to the CRC sequence has been received normally. Dominant has higher priority than recessive, so if the ACK slot is dominance after transmission, so the transmitting node will be able to confirm that one of the receiving nodes has succeeded in reception.

The ACK delimiter (the "DEL" between the "ACK" and "EOF" in <FIG>) is made up of <NUM>-bit recessive, and is a sectioning symbol representing the end of the ACK.

The EOF is made up of <NUM>-bits recessive, and represents the end of the data frame.

<FIG> is a configuration diagram of the master ECU <NUM>. The master ECU <NUM> includes a frame transmission/reception unit <NUM>, a frame analyzing unit <NUM>, a reception ID judging unit <NUM>, a reception ID list storing unit <NUM>, an expiration data confirming unit <NUM>, a MAC processing unit <NUM>, a counter storing unit <NUM>, a session key list storing unit <NUM>, an encryption processing unit <NUM>, a shared key list storing unit <NUM>, a session key generating unit <NUM>, and a frame generating unit <NUM>. These components are functional components, and the functions thereof are realized by a communication circuit in the master ECU <NUM>, a processor or digital circuit of the like that executes the program stored in the memory, and so forth.

The frame transmission/reception unit <NUM> transmits and receives frames following the CAN protocol to and from the bus <NUM>. Frames are received from the bus <NUM> one bit at a time. and transferred to the frame analyzing unit <NUM>. The contents of frames received from the frame generating unit <NUM> are transmitted to the bus <NUM> one bit at a time.

The frame analyzing unit <NUM> receives the values of frames from the frame transmission/reception unit <NUM>, and performs analysis so as to map to the fields in the frame format stipulated in the CAN protocol. The frame analyzing unit <NUM> transfers a value determined to be an ID field to the reception ID judging unit <NUM>. The frame analyzing unit <NUM> decides, in accordance with determination results notified from the reception ID judging unit <NUM>, whether to transfer the value of an ID field (CAN-ID) and a data field appearing after the ID field, to the MAC processing unit <NUM>, or to cancel reception of frames after having received the determination results (i.e., to stop analyzing that frame). After transferring to the MAC processing unit <NUM>, the processing results at the MAC processing unit <NUM> (the MAC verification results) are received, and in a case of having been determined to be normal (i.e., in a case where MAC verification has been successful), the value of the ID field and the data field appearing after the <NUM> field are notified to the expiration data confirming unit <NUM>. In a case where the frame is judged not to be following the CAN protocol, such as the CRC value not matching, or an item fixed to dominant being recessive, the frame analyzing unit <NUM> notifies the frame generating unit <NUM> to transmit an error frame. In a case of having received an error frame, i.e., in a case of having analyzed from the value of a received frame that the frame is an error frame, the frame analyzing unit <NUM> discards that frame thereafter, i.e., stops analyzing the frame.

The reception ID judging unit <NUM> receives the value of the ID field notified from the frame analyzing unit <NUM> and determines whether or not to receive the fields in the frame after that ID field, in accordance with a CAN-ID list that the reception ID list storing unit <NUM> stores. The reception ID judging unit <NUM> notifies the determination results thereof to the frame analyzing unit <NUM>.

The reception ID list storing unit <NUM> stores the reception ID list, that is a list of CAN-IDs that the master ECU <NUM> receives. <FIG> illustrates an example of a reception ID list.

The expiration data confirming unit <NUM> acquires a value indicating the expiration date of the shared key, that is the value of the data field, for an expiration date notification frame identified by the CAN-ID received from the frame analyzing unit <NUM>, and inspects the expiration date by comparing with the current point-in-time. In a case where the expiration date has already elapsed, the expiration data confirming unit <NUM> records this in a log. Also, in a case where the expiration date has already elapsed, the expiration data confirming unit <NUM> notifies the driver by displaying information on the display device to the effect that the expiration date has elapsed. In a case where the expiration date has elapsed, the master ECU <NUM> can keep session keys from being transmitted to the ECUs.

The MAC processing unit <NUM> calculates a MAC value using a session key corresponding to the CAN-ID that is stored in the session key list storing unit <NUM>, with regard to a value obtained by linking the CAN-ID notified from the frame analyzing unit <NUM>, a portion of the data field excluding the MAC value, and a reception counter value corresponding to the CAN-ID stored in the counter storing unit <NUM>. The MAC processing unit <NUM> then performs comparison and verification against the MAC value included in the data field, and notifies the verification results to the frame analyzing unit <NUM>. The result of having obtained a MAC value by calculation, with regard to the value (linked value) obtained by linking the CAN-ID notified from the frame generating unit <NUM>, a value of data for the data field to be transmitted, and a transmission counter value corresponding to the CAN-ID stored in the counter storing unit <NUM>, is notified to the frame generating unit <NUM>. AES-CMAC (NPL <NUM>) is used here as the MAC calculation method, with calculation being performed on the above-described linked value using a MAC key (session key) of a value padded to a predetermined block worth, and the four leading bytes of the obtained calculation results are taken as the MAC value. Note that the size of the MAC value, and the calculation method, are only an example, and these are not restrictive. A MAC is generated reflecting a transmission counter value incremented each time a frame is transmitted, so even if data frames including the same data are transmitted multiple times, for example, the MAC value given (i.e., added) to the data frame changes with each transmission.

The counter storing unit <NUM> stores counter values necessary for calculating MAC values, one each for transmission and for receipt, for each CAN-ID. In a case where a frame has been successfully transmitted, the transmission counter value is incremented, and in a case where a frame has been successfully received, the reception counter value is incremented.

The session key list storing unit <NUM> stores a list where session keys used for encryption processing relating to frames, i.e., session keys used by the MAC processing unit <NUM> to calculate MAC values, are correlated with CAN-IDs (session key list). The session key list storing unit <NUM> saves session keys notified from the encryption processing unit <NUM> along with CAN-IDs as a session key list.

The encryption processing unit <NUM> receives a session key generating request from the frame generating unit <NUM> along with a CAN-ID, notifies the session key generating unit <NUM> of the session key generating request, and receives a session key generated and issued (transmitted) by the session key generating unit <NUM>. The encryption processing unit <NUM> encrypts the issued session key using a shared key (shared key corresponding to the CAN-ID) stored in the shared key list storing unit <NUM>, and notifies the frame generating unit <NUM>. The encryption processing unit <NUM> also notifies the session key list storing unit <NUM> of the session key issued by the session key generating unit <NUM> along with the CAN-ID, so as to be saved in the session key list storing unit <NUM>.

The shared key list storing unit <NUM> stores a shared key list that is a list correlating shared keys shared beforehand for use in transmission of session keys among the ECUs, with the CAN-IDs. One shared key is designated for each CAN-ID. The correlation between a certain CAN-ID and shared key in the shared key list indicates the correlation between the ECU transmitting the frame including that CAN-ID, and the shared key. Besides designating a shared key for each CAN-ID, one shared key may be designated for all ECUs. Alternatively, in a case where the bus <NUM> is of a configuration where multiple sub-nets are connected by a gateway, the bus <NUM> may designate one shared key for each sub-net (each set of ECUs connected to a sub-net). <FIG> illustrates an example of a shared key list that the shared key list storing unit <NUM> stores.

The session key generating unit <NUM> receives the session key generating request, and generates and issues a session key. Examples of a session key generating method include using a method of calculating a session key using a hash function, which is a one-way function, from a serial ID unique to the master ECU <NUM>. <FIG> illustrates an example of a session key list that the session key generating unit <NUM> generates and the session key list storing unit <NUM> stores.

The frame generating unit <NUM> configures an error frame in accordance with the error frame transmission request notified from the frame analyzing unit <NUM>, and notifies the frame transmission/reception unit <NUM> to transmit the error frame.

The frame generating unit <NUM> notifies the encryption processing unit <NUM> of the session key generating request, and receives the encrypted session key. The frame generating unit <NUM> notifies the MAC processing unit <NUM> of the CAN-ID decided beforehand, and the encrypted session key notified from the encryption processing unit, and receives the MAC value calculation results. The frame generating unit <NUM> configures a data frame to which is attached the encrypted session key received from the encryption processing unit <NUM>, the MAC value notified from the MAC processing unit <NUM>, and the predetermined CAN-ID, and notifies the frame transmission/reception unit <NUM> to transmit the data frame.

The master ECU <NUM> has a function of, upon detecting that the vehicle in which the onboard network system <NUM> is installed is in an accessory-on (ACC-ON) state, causing the frame generating unit <NUM> to generate an inquiry frame for the expiration date of the shared key, and transmitting to the frame transmission/reception unit <NUM>. Vehicle states such as starting the engine, ACC-ON, stopped, and so forth, may be detected by detection mechanisms such as various types of sensors and so forth. and transmitted from the detection mechanisms directly to the master ECU <NUM> or via other ECUs.

<FIG> is a diagram illustrating an example of a reception ID list (CAN-ID list) that the master ECU <NUM> stores in the reception ID list storing unit <NUM>. The reception ID list illustrated in the drawing is used for the master ECU <NUM> to selectively receive and process frames of which the CAN-ID value is one of "<NUM>", "<NUM>", "<NUM>", "<NUM>", "<NUM>", "<NUM>", "<NUM>", and "<NUM>". In this example, the CAN-IDs "<NUM>", "<NUM>", "<NUM>", and "<NUM>" of expiration date notification frames that the ECUs transmit are values obtained by adding a certain values to the CAN-IDs "<NUM>", "<NUM>", "<NUM>", and "<NUM>" that these ECUs basically transmit.

<FIG> is a diagram illustrating an example of a shared key list that the master ECU <NUM> stores in the shared key list storing unit <NUM>. The shared key list is a list where CAN-IDs and shared keys (Km) are correlated. The shared key list illustrated in the drawing indicates that shared key "0x1A4DE4FC02F66B77" has been assigned to CAN-ID "<NUM>", shared key "0x27AB6EAC81773F65" has been assigned to CAN-ID "<NUM>", shared key "0xCB939EA0CE378A7E" has been assigned to CAN-ID "<NUM>", and shared key "0x03E46FF28CBC8D7A" has been assigned to CAN-ID "<NUM>".

<FIG> is a diagram illustrating an example of a session key list that the master ECU <NUM> stores in the session key list storing unit <NUM>. The session key list is a list where CAN-IDs and session keys (Ks) are correlated. The session key list illustrated in the drawing indicates that the same session key "0x7678A87B" has been assigned to the CAN-IDs "<NUM>", "<NUM>", "<NUM>", and "<NUM>".

<FIG> is a configuration diagram of the ECU 100a. The ECU 100a is configured including a frame transmission/reception unit <NUM>, a frame analyzing unit <NUM>, a reception ID judging unit <NUM>, a reception ID list storing unit <NUM>, a decryption processing unit <NUM>, a shared key list storing unit <NUM>, a MAC processing unit <NUM>, a session key storing unit <NUM>, a counter storing unit <NUM>, a frame generating unit <NUM>, and a data acquisition unit <NUM>. These components are functional components, and the functions thereof are realized by a communication circuit in the ECU 100a, a processor or digital circuit of the like that executes the control program stored in the memory, and so forth. The ECUs 100b through 100d also have basically the same configuration as the ECU 100a.

The frame transmission/reception unit <NUM> transmits and receives frames following the CAN protocol to and from the bus <NUM>. Frames are received from the bus <NUM> one bit at a time, and transferred to the frame analyzing unit <NUM>. The contents of frames received from the frame generating unit <NUM> are transmitted to the bus <NUM>.

The frame analyzing unit <NUM> receives the values of frames from the frame transmission/reception unit <NUM>, and performs analysis so as to map to the fields in the frame format stipulated in the CAN protocol. The frame analyzing unit <NUM> transfers a value determined to be an ID field to the reception ID judging unit <NUM>. The frame analyzing unit <NUM> decides, in accordance with determination results notified from the reception ID judging unit <NUM>, whether to transfer the value of an ID field (CAN-ID) and a data field appearing after the ID field, to the MAC processing unit <NUM>, or to cancel reception of frames after having received the determination results (i.e., to stop analyzing that frame). After transferring to the MAC processing unit <NUM>, the processing results at the MAC processing unit <NUM> (the MAC verification results) are received, and in a case of having been determined to be normal (i.e., in a case where MAC verification has been successful), the value of the ID field and the data field appearing after the ID field are notified to the decryption processing unit <NUM>. In a case where the frame is judged not to be following the CAN protocol, the frame analyzing unit <NUM> notifies the frame generating unit <NUM> to transmit an error frame. In a case of having received an error frame, i.e., in a case of having analyzed from the value of a received frame that the frame is an error frame, the frame analyzing unit <NUM> discards that frame thereafter, i.e., stops analyzing the frame.

The reception ID list storing unit <NUM> stores the reception ID list, that is a list of CAN-IDs that the ECU 100a receives. <FIG> illustrates an example of a reception ID list that is a CAN-ID list.

The decryption processing unit <NUM> is notified of the encrypted session key by the frame analyzing unit <NUM>, along with a CAN-ID decided beforehand for transmission of the session key, and thereupon uses the shared key that the shared key list storing unit <NUM> stores to perform decryption processing, and acquires the session key. The acquired session key is notified to the session key storing unit <NUM> to be saved. In a case of having received notification from the frame analyzing unit <NUM> of data along with a CAN-ID other than for session key transmission, the decryption processing unit <NUM> performs processing according functions that differ for each ECU, in accordance with the received data. For example, the ECU 100a connected to the engine <NUM> has a function of sounding an alarm sound in a state where a door is open and the speed is above <NUM>. The ECU 100a has a speaker or the like for sounding the alarm sound, for example, the ECU 100a manages data (e.g., information indicating the state of the door) received from other ECUs, and performs processing such as sounding an alarm sound under predetermined conductions based on the speed acquired from the shared engine <NUM>, for example.

The shared key list storing unit <NUM> stores a shared key corresponding to the CAN-ID that the ECU 100a uses for transmitting (i.e., the shared key corresponding to the ECU 100a), and information indicating the expiration date of that shared key. An example of a shared key stored by the shared key list storing unit <NUM> will be described later with reference to <FIG>.

The MAC processing unit <NUM> calculates a MAC value using a session key corresponding to the CAN-ID that is stored in the session key storing unit <NUM>. with regard to a value obtained by linking the CAN-ID notified from the frame analyzing unit <NUM>, a portion of the data field excluding the MAC value, and a reception counter value corresponding to the CAN-ID that is stored In the counter storing unit <NUM>. The MAC processing unit <NUM> then performs comparison and verification against the MAC value included In the data field, and notifies the verification results to the frame analyzing unit <NUM>. The result of having obtained a MAC value by calculation, with regard to the value (linked value) obtained by linking the CAN-ID notified from the frame generating unit <NUM>, a value of data for the data field to be transmitted, and a transmission counter value corresponding to the CAN-ID stored in the counter storing unit <NUM>, is notified to the frame generating unit <NUM>. AES-CMAC (NPL <NUM>) is used here as the MAC calculation method, with calculation being performed on the above-described linked value using a MAC key (session key) of a value padded to a predetermined block worth, and the four leading bytes of the obtained calculation results are taken as the MAC value. Note that the size of the MAC value, and the calculation method, are only an example, and these are not restrictive.

The session key storing unit <NUM> stores the session key for encryption processing relating to frames, i.e., the session key that the MAC processing unit <NUM> uses for calculating MAC values, in a correlated manner with the CAN-ID that the ECU 100a uses for transmission. The session key storing unit <NUM> saves the session key notified from the decryption processing unit <NUM>.

The counter storing unit <NUM> stores counter values necessary for calculating MAC values, one each for transmission and for reception, for each CAN-ID. In a case where a frame has been successfully transmitted, the transmission counter value is incremented, and in a case where a frame has been successfully received, the reception counter value is incremented.

The frame generating unit <NUM> notifies the MAC processing unit <NUM> of the data field value decided based on the data notified from the data acquisition unit <NUM>, and receives the MAC value calculation results. The frame generating unit <NUM> configures a data frame from the data field value decided based on the data notified from the data acquisition unit <NUM>, the MAC value notified from the MAC processing unit <NUM>, and the CAN-ID decided beforehand, and notifies the frame transmission/reception unit <NUM> to transmit the data frame.

The data acquisition unit <NUM><NUM> acquires data indicating the states of devices, sensors and the like, connected to the ECUs, and notifies the frame generating unit <NUM>.

The ECU 100a has a function of, upon receiving frame inquiring the expiration date of a shared key, causing the frame generating unit <NUM> to generate an expiration date notification frame in which the expiration date is data and a MAC has been attached, and transmitting the frame. The ECU 100a and the other ECUs may have functions other than those exemplarily illustrated here. The contents of frames transmitted by each of the ECUs 100a through 100d will be described later with reference to <FIG>.

<FIG> is a diagram illustrating an example of a reception ID list that the ECU 100a and ECU 100c each stores. The reception ID list illustrated in the drawing is used to selectively receive and process frames of which the CAN-ID value is one of "<NUM>", "<NUM>", and so forth. Although omitted from illustration in <FIG>, the reception ID list stored in each of the ECU 100a and ECU 100c further includes a CAN-ID decided beforehand for transmitting a session key for each ECU, and a CAN-ID decided beforehand for a shared key expiration date inquiry from the master ECU <NUM>.

<FIG> is a diagram illustrating an example of a reception ID list that the ECU 100b and ECU 100d each stores. The reception ID list illustrated in the drawing is used to selectively receive and process frames of which the CAN-ID value is one of "<NUM>", "<NUM>", and so forth. Although omitted from illustration in <FIG>, the reception ID list stored in each of the ECU 100b and ECU 100d further includes a CAN-ID decided beforehand for transmitting a session key for each ECU, and a CAN-ID decided beforehand for a shared key expiration date inquiry from the master ECU <NUM>.

<FIG> is a diagram illustrating an example of a CAN-ID and data field (data) in frames transmitted from the ECU 100a connected to the engine <NUM>. The CAN-ID of the frames that the ECU 100a transmits relating to speed is "<NUM>". In the value in the data field, the first one byte represents speed, the next one byte represents the counter (transmission counter value), and the next four bytes represent the MAC value. The speed (km/hour) assumes a range from a minimum of <NUM> (km/hour) to a maximum of <NUM> (km/hour). In order from the top row to lower rows in <FIG> is illustrated the CAN-IDs and data corresponding to the frames sequentially transmitted from the ECU 100a, representing the way in which acceleration is performed from <NUM>/hour in <NUM>/hour increments.

<FIG> is a diagram illustrating an example of a CAN-ID and data field (data) in frames transmitted from the ECU 100b connected to the brakes <NUM>. The CAN-ID of the frames that the ECU 100b transmits relating to the degree of braking is "<NUM>". In the value in the data field, the first one byte represents the degree of braking, the next one byte represents the counter (transmission counter value), and the next four bytes represent the MAC value. The degree of braking is represented by percentage (%), with a state where no braking is being performed at all being <NUM>(%), and a state of full-braking is <NUM> (%). In order from the top row to lower rows in <FIG> is illustrated the CAN-IDs and data corresponding to the frames sequentially transmitted from the ECU 100b, representing the way in which braking is gradually being reduced from <NUM>%.

<FIG> is a diagram illustrating an example of a CAN-ID and data field (data) in frames transmitted from the ECU 100c connected to the door open/closed sensor <NUM>. The CAN-ID of the frames that the ECU 100c transmits relating to the open/closed state of the door is "<NUM>". In the value in the data field, the first one byte represents the open/closed state of the door, the next one byte represents the counter (transmission counter value), and the next four bytes represent the MAC value. The open/closed state of the door is represented by "<NUM>" for a state where the door is opened, and "<NUM>" for a state where the door is closed. In order from the top row to lower rows in <FIG> is illustrated the CAN-IDs and data corresponding to the frames sequentially transmitted from the ECU 100c, representing the way in which the door is gradually transitioning from an open state to a closed state.

<FIG> is a diagram illustrating an example of a CAN-ID and data field (data) in frames transmitted from the ECU 100d connected to the window open/closed sensor <NUM>. The CAN-ID of the frames that the ECU 100d transmits relating to the open/closed state of the window is "<NUM>". In the value in the data field, the first one byte represents the open/closed state of the window, the next one byte represents the counter (transmission counter value), and the next four bytes represent the MAC value. The open/closed state of the window is represented by percentage (%), with a state where the window is completely closed being <NUM>(%), and a state where the window is completely open being <NUM> (%). In order from the top row to lower rows in <FIG> is illustrated the CAN-IDs and data corresponding to the frames sequentially transmitted from the ECU 100d, representing the way in which the window is gradually transitioning from a closed state to an open state.

<FIG> is a diagram illustrating the shared key that the ECU 100a stores, and information indicating the expiration date thereof. The drawing indicates that a shared key "0x1A4DE4FC02F66877" having the expiration date of "<NUM>/<NUM>/<NUM>-!" has been assigned to the CAN-ID "<NUM>" that the ECU 100a transmits. This shared key is used for decoding the session key transmitted from the master ECU <NUM>. Note that the shared key may be set to the ECU at the stage of manufacturing or shipping or the like of the ECU, and updated by connecting a dedicated tool to the onboard network system <NUM>.

The following is a description of operations of the master ECU <NUM> transmitting a session key to the ECU 100a, with reference to <FIG>.

<FIG> is a diagram illustrating an example of a session key distribution sequence performed between the master ECU <NUM> and the ECU 100a. Although the master ECU <NUM> distributes session keys to the ECUs 100b through 100d in the same way, description will be made here focusing on the ECU 100a that is the ECU that transmits frames with the CAN-ID "<NUM>".

First, the master ECU <NUM> generates a certain session key Ks1 at the session key generating unit <NUM> (step S1001).

Next, the master ECU <NUM> uses the shared key Km (see <FIG>) corresponding to the CAN-ID "<NUM>" to encrypt the session key Ks1 and generate an encrypted session key Ks1' at the encryption processing unit <NUM> (step S1002).

The master ECU <NUM> generates a MAC using the generated encrypted session key Ks1' and a counter (transmission counter value) at the MAC processing unit <NUM> (step S1003).

The master ECU <NUM> transmits a data frame including in the data field the encrypted session key Ks1' and the MAC value, to which has been attached the CAN-ID decided beforehand for transmission of the session key to the ECU 100a corresponding to the CAN-ID "<NUM>" (step S1004). Accordingly, the data frame appears on the bus <NUM>.

The master ECU <NUM> starts receiving the data frame flowing on the bus to confirm the transmitted frame (step S1005), confirms that the data flowing on the bus matches the data frame which it is transmitting itself (step S1006), and if not matching, transmits an error frame (step S1007).

When a data frame appears on the bus <NUM>, the ECU 100a starts receiving the data frame flowing on the bus (step S1008).

The ECU 100a receives the CAN-ID included in the data frame flowing on the bus at the reception ID judging unit <NUM>, and checks whether or not it is an ID listed in the reception ID list that the reception ID list storing unit <NUM> stores (step S1009). In a case where the CAN-ID is a CAN-ID that is not listed in the reception ID list, the data frame being received is discarded, and the frame reception ends. Note that the CAN-ID decided beforehand for session key transmission is listed in the reception ID list.

The ECU 100a extracts the MAC value from the data field of the received data frame and performs verification at the MAC processing unit <NUM> (step S1010). In a case where verification fails, the data frame being received is discarded, and the frame reception ends.

The ECU 100a acquires the encrypted session key Ks1' from the received data field, and extracts the session key Ks1 by performing decryption processing at the decryption processing unit <NUM> using the shared key that the shared key list storing unit <NUM> stores (step S1011). In a case where decryption fails, processing regarding the received frame ends.

The ECU 100a saves the extracted session key Ks1 in the session key storing unit <NUM> (step S1012). The ECU 100a uses this session key Ks1 to generate or verify MAC values at the time of transmission of reception of the next and subsequent data frames.

The ECUs 100b through 100d can each use a shared key shared with the master ECU <NUM> so as to acquire the session key Ks1 from the master ECU <NUM> in the same way as the ECU 100a.

The following is a description of operations of message authentication relating to transmission of a data frame between the ECU 100a and the ECU 100c, with reference to <FIG>.

<FIG> is a diagram illustrating an example of a message authentication sequence performed between the ECU 100a and ECU 100c. Although message authentication between the ECU 100a and the ECU 100c is illustrated here, the same operations are performed between other ECUs, between the ECU 100b and ECU 100d for example, between the ECU 100a and the master ECU <NUM>, and so forth. The ECU 100c has basically the same configuration as the ECU 100a, so components of the ECU 100c will be reference using the same reference numerals as for the components of the ECU 100a (See <FIG>).

First, the ECU 100a generates data to be transmitted at the frame generating unit <NUM> (step S1101).

The ECU 100a then generates a MAC corresponding to the value of the data generated in step S1101 and the counter (transmission counter value) at the MAC processing unit <NUM> (step Si <NUM>). The ECU 100a uses the session key Ks1 stored in the session key storing unit <NUM> to generate this MAC.

Next, the ECU 100a increments the transmission counter value corresponding top the CAN-ID "<NUM>" by <NUM> (step S1103).

The ECU 100a transmits the data frame including the value of the data and the counter in the data field, with the CAN-ID "<NUM>" attached, by the frame transmission/reception unit <NUM> (step S1104). Accordingly, the data frame appears on the bus <NUM>.

The ECU 100a starts receiving the data frame flowing on the bus to confirm the transmitted frame (step S1105), confirms that the data flowing on the bus matches the data frame which it is transmitting itself (step S1106), and if not matching, transmits an error frame (step S1107).

When a data frame appears on the bus <NUM>, the ECU 100c starts receiving the data frame flowing on the bus (step S1108).

The ECU 100c receives the CAN-ID included in the data frame flowing on the bus at the reception ID judging unit <NUM>, and checks whether or not it is an ID listed in the reception ID list (see <FIG>) that the reception ID list storing unit <NUM> stores (step S1109). In a case where the CAN-ID is a CAN-ID that is not listed in the reception ID list, the data frame being received is discarded, and the frame reception ends.

The ECU 100c extracts the MAC value from the data field of the received data frame and performs verification at the MAC processing unit <NUM> (step S1110). In a case where verification fails, the data frame being received is discarded, and the frame reception ends. The ECU 100c uses the session key Ks1 stored at the session key storing unit <NUM> in the verification of the MAC in step S1110. In a case where verification has been successful, the ECU 100c increments the reception counter value corresponding to the CAN-ID "<NUM>" by <NUM> (step S1111).

Following step S1111, the ECU 100c performs processing in accordance with the received data frame (step S1112).

The following is a description of operations of the master ECU <NUM> inspecting (verifying) the security state relating to shared keys, by confirmation of the expiration date, with reference to <FIG>.

<FIG> illustrates an example of a shared key verification sequence by the master ECU <NUM>, the ECU 100a, the ECU 100b, the ECU 100c. and the ECU 100d. Note that this shared key verification sequence is executed when the vehicle in which is installed the onboard network system <NUM> is in a particular state (e.g., a stopped state before driving), for example. As for a specific example, this is executed immediately after entering the accessory-on (ACC-ON) state.

The master ECU <NUM> transmits an expiration date inquiry frame regarding the shared keys that the ECUs store shared with the master ECU <NUM> (step S1201). Accordingly, an expiration date inquiry frame appears on the bus <NUM>.

The ECUs 100a through 100d each receive the expiration date inquiry frame from the bus <NUM>, and transmit an expiration date notification frame including data, where the MAC has been attached to the expiration date of the shared key that each store, in the data field (step S1202). That is to say, the ECU 100a, the ECU 100b, the ECU 100c, and the ECU 100d transmit expiration date notification frames to which the respective CAN-IDs "<NUM>", "<NUM>", "<NUM>", and "<NUM>". have been attached. Accordingly, the expiration date notification frames sequentially appear on the bus <NUM>.

The master ECU <NUM> verifies the MAC values included in the expiration date notification frames sequentially appearing on the bus <NUM>, and compares the expiration date included in the expiration date notification frames with the current point-in-time, thereby confirming that the expiration date of the shared keys obtained from all ECUs is later than the current point-in-time (i.e., that all of the shared keys are within the expiration date) (step S1203). If there is a shared key that is not within the expiration date, the master ECU <NUM> records and saves information indicating that the expiration date has elapsed in a log (step S1204). and displays information on the display device relating to the fact that the expiration date has elapsed (information indicating that updating of the shared key is necessary and so forth), thus making notification to the driver (step S1205). Note that in a case where the expiration date of any one of the shared keys has elapsed, for example, the master ECU <NUM> can keep session keys from being transmitted.

In the onboard network system <NUM> according to the first embodiment, the master ECU <NUM> (a first-type ECU serving as a key managing device so as to speak) confirms (inspects) the expiration date of the shared keys that the ECUs (second-type ECU) store, in a case where the vehicle is in a particular state, such as a stopped state, thereby inspecting whether or not the risk of leakage of the shared keys that the ECUs store has increased (whether or not a state where updating of the shared key is necessary) with regard to security. That is to say, a first-type ECU receives a frame including information indicating the expiration date of a shared key that a second-type ECU stores and distinguishes whether or not the expiration date has already elapsed, thereby inspecting the security state of the shared key, and performs communication to give the second-type ECU a session key in a case where the expiration date has not expired, while performing control such as notification or the like (display on the display device or the like) in a case where the expiration date has elapsed. The shared keys that the ECUs (second-type ECU) store are shared between the ECUs and the master ECU (first-type ECU), and are used for transmission of session keys. The session keys are used as keys in encryption processing (processing including generating and verifying MACs, etc.)when transmitting and receiving frames among the ECUs. This encryption processing may include various types of conversion processing, such as encryption, decryption, signature, verification, and so forth. Accordingly, in a case where the security state is unsuitable (in a case where the risk of leakage of a shared key is higher) in the onboard network system <NUM> where the security state of shared keys is configured using the expiration date, safety can be secured by notification, recording in a log, and so forth, and thereby can prevent distribution of invalid session keys. Performing the shared key security state inspection in a stopped state before the vehicle drives, such as at the time of ACC-ON, and avoiding increased processing load on the ECUs and increased traffic on the bus <NUM> while the vehicle is driving, is useful.

The onboard network system <NUM> including a master ECU <NUM> (key managing device) which is a partial modification of the above-described master ECU <NUM> will be described below.

The master ECU <NUM> Is basically the same as the master ECU <NUM>, but the method of verifying the expiration date of the shared keys that the ECUs store differs. That is to say, the master ECU <NUM> has a function of verifying the expiration date of the shared keys that the ECUs store by communication with a server that is external from the onboard network system <NUM> (outside of the vehicle).

<FIG> is a configuration diagram of the master ECU <NUM>. The master ECU <NUM> includes the frame transmission/reception unit <NUM>, the frame analyzing unit <NUM>, the reception ID judging unit <NUM>, the reception ID list storing unit <NUM>, the MAC processing unit <NUM>, the counter storing unit <NUM>, the session key list storing unit <NUM>, the encryption processing unit <NUM>, the shared key list storing unit <NUM>, the session key generating unit <NUM>, the frame generating unit <NUM>, and a server communication unit <NUM>. These components are functional components, and the functions thereof are realized by a communication circuit in the master ECU <NUM>, a processor or digital circuit of the like that executes the control program stored in the memory, and so forth. Note that the components of the master ECU <NUM> that are the same as the components of the master ECU <NUM> (see <FIG>) are denoted by the same reference numerals, and description will be omitted as appropriate.

In a case of having succeeded in verification, as the result of verifying a MAC of a data frame at the MAC processing unit <NUM>, the frame analyzing unit <NUM> notifies the server communication unit <NUM> of the CAN-ID of the frame and the value of the data field.

The server communication unit <NUM> has a function of communicating with an external server wirelessly. The server communication unit <NUM> correlates the CAN-IDs of all data frames received from the frame analyzing unit <NUM> and the values of the data fields, notifies the server, and receives determination results from the server. In a case where an error occurs as a result of determination, the driver is notified by displaying the content of the error on the display device, for example. In a case where the determination results at the server regarding an expiration date notification frame are an error, the master ECU <NUM> can keep transmission of session keys to the ECUs from being performed.

Note that the external server is a computer communicable with the master ECU <NUM>, and has a function of, in a case of having received from the master ECU <NUM> a CAN-ID regarding an expiration date notification frame and a value indicating the expiration date that is the value of the data field, making judgment regarding whether or not the expiration date has elapsed, based on the current point-in-time or other information. In a case where this has not elapsed, a determination result of normal is transmitted to the master ECU <NUM>, and if this has elapsed, an error is transmitted.

The following is a description of operations of the master ECU <NUM> inspecting the security state relating to shared keys, by communication with the server, with reference to <FIG>.

<FIG> illustrates an example of a shared key verification sequence by the master ECU <NUM>, the ECU 100a, the ECU 100b, the ECU 100c, and the ECU 100d. Note that this shared key verification sequence is executed when the vehicle in which is installed the onboard network system <NUM> is in a particular state (e.g., a stopped state before driving), for example. As for a specific example, this is executed immediately after entering the accessory-on (ACC-ON) state. Note that processing (steps) in <FIG> that are the same as those shown in <FIG> are denoted by the same reference numerals, and description will be omitted here.

In step S1202. expiration date notification frames transmitted by the ECU 100a, ECU 100b, ECU 100c, and ECU 100d sequentially appear on the bus <NUM>.

The master ECU <NUM> transmits to the server the CAN-IDs of the expiration date notification frames sequentially appearing on the bus <NUM> and the values included in the expiration date notification frames. Confirmation is made regarding whether or not the expiration date of the shared keys has not elapsed, by whether or not the determination results returned from the server are normal (step S1303). In a case where the determination results form the server are an error, i.e., the expiration date of the shared key has expired, the master ECU <NUM> notifies the drive by display information relating to the fact that the expiration date has expired (information indicating that the updating of the shared key is necessary, etc.) on the display device (step S1304). Note that in a case where the expiration date of any one of the shared keys has elapsed, for example, the master ECU <NUM> can keep session keys from being transmitted.

In the onboard network system <NUM> according to the modification of the first embodiment, the master ECU <NUM> communicates with an external server in a case where the vehicle is in a particular state such as a stopped state or the like, and causes the server to determine the expiration date of shared keys that the ECUs store, thereby verifying whether or not the security state of the shared keys is appropriate, i.e., whether or not the state is that where the risk of leakage of shared keys stored by the ECUs is higher (whether or not a state where the shared keys need to be updated). In a case where the security state is inappropriate, safety can be secured by notification and the like, and distribution of unauthorized session keys can be prevented. The external server can collect information of the expiration date of the shared keys of the ECUs from the master ECU <NUM> in the onboard network system <NUM> installed in each of multiple vehicles and confirm the integrity, so the security state of the shared keys can be determined more appropriately.

As an embodiment of the present invention, an onboard network system will be described including a master ECU (key managing device) <NUM> that saves a shared key list, which is information correlating CAN-IDs and serial IDs for each ECU, and verifies the security state of the shared keys based on the shared key list. The onboard network system according to the present embodiment has the master ECU <NUM> in the onboard network system <NUM> according to the first embodiment (see <FIG>) replaced with the master ECU <NUM> (described later). The onboard network system according to the present embodiment has the ECU 100a in the onboard network system <NUM> according to the first embodiment replaced with a ECU 20100a (described later) having a function of storing a serial ID unique to the ECU and transmitting a serial ID notification frame to make notification of this serial ID. The onboard network system according to the present embodiment also has ECUs 20100b through 20100d having the same function as the ECU 20100a, instead of the ECUs 100b through 100d.

In the same way as the master ECU <NUM>, the master ECU <NUM> is connected to the bus <NUM>, as a type of ECU serving as a key managing device. The master ECU <NUM> stores a shared key shared with one or more ECUs out of the multiple ECUs connected to the bus <NUM> besides itself, to use for transmitting session keys mutually between the one or more ECUs for encryption processing relating to frames (including MAC processing), and functions to manage the security state of the shared key.

<FIG> is a configuration diagram of the master ECU <NUM>. The master ECU <NUM> includes the frame transmission/reception unit <NUM>, the frame analyzing unit <NUM>, the reception ID judging unit <NUM>, the reception ID list storing unit <NUM>, the MAC processing unit <NUM>, the counter storing unit <NUM>, the session key list storing unit <NUM>, the encryption processing unit <NUM>, a shared key list storing unit <NUM>, the session key generating unit <NUM>, the frame generating unit <NUM>, and a list confirmation unit <NUM>. Note that the components that are the same as those shown in the first embodiment are denoted by the same reference numerals, and description will be omitted as appropriate.

The shared key list storing unit <NUM> stores a shared key list that is a list correlating shared keys shared beforehand for use in transmission of session keys among the ECUs, with the CAN-IDs, and further correlating serial IDs for each ECU. For each CAN-ID, there are designated the serial ID of one ECU that transmits a frame with that CAN-ID, and one corresponding shared key. Besides designating a shared key for each CAN-ID, one shared key may be designated for all ECUs or multiple ECUs. In this case, multiple serial IDs correspond to a single shared key. Alternatively, in a case where the bus <NUM> is of a configuration where multiple sub-nets are connected by a gateway, the bus <NUM> may designate one shared key for each sub-net (each set of ECUs connected to a sub-net). <FIG> illustrates an example of a shared key list that the shared key list storing unit <NUM> stores.

In a case of having succeeded in verification as a result of the verification of the MAC of the data frame in the MAC processing unit <NUM>, the frame analyzing unit <NUM> notifies the list confirmation unit <NUM> of the CAN-ID of that data frame and the value of the data field.

The list confirmation unit <NUM> acquires a value indicating a serial ID unique to the ECU that is the transmission source of the frame at the frame analyzing unit <NUM>. the value being a value of the data field of a serial ID notification frame identified by the CAN-ID, and compares with the serial ID in the shared key list that the shared key list storing unit <NUM> stores, to determine whether matching or not. In a case where the serial IDs do not match, the list confirmation unit <NUM> performs error processing, of recording in a log or the like. Another example of error processing besides recording in a log include displaying information relating to the error on the display device, thereby notifying the driver, not performing transmission of session keys to the ECUs, and so forth.

Note that the reception ID list that the reception ID list storing unit <NUM> stores has listed the CAN-IDs "<NUM>", "<NUM>", "<NUM>", and "<NUM>", of the serial ID notification frames that the ECUs 20100a through 20100d transmit, instead of the CAN-IDs "<NUM>", "<NUM>", "<NUM>", and "<NUM>". Of the expiration date notification frames illustrated in the first embodiment. In the example of the CAN-IDs used here, the CAN-IDs "<NUM>", "<NUM>", "<NUM>", and "<NUM>" of serial ID notification frames that the ECUs transmit are values obtained by adding a certain values to the CAN-IDs "<NUM>", "<NUM>", "<NUM>", and "<NUM>" that these ECUs basically transmit.

<FIG> is a diagram illustrating an example of a shared key list that the master ECU <NUM> stores in the shared key list storing unit <NUM>. The shared key list is a list where CAN-IDs and shared keys (Km) and serial IDs are correlated. The serial ID is an ID unique to each ECU. The manufacture or the like of the ECUs, for example, gives the ECUs individual serial IDs. The shared key list illustrated in <FIG> indicates that shared key "0x1A4DE4FC02F66B77" and serial ID "0x10000001" have been assigned to CAN-ID "<NUM>", shared key "0x27AB6EAC81773F65" and serial ID "0x10000002" have been assigned to CAN-ID "<NUM>", shared key "0xCB939EA0CE378A7E" and serial ID "0x10000003" have been assigned to CAN-ID "<NUM>", and shared key "0x03E46FF28CBC8D7A" and serial ID "0x10000004" have been assigned to CAN-ID "<NUM>".

<FIG> is a configuration diagram of the ECU 20100a. The ECU 20100a is configured including the frame transmission/reception unit <NUM>, the frame analyzing unit <NUM>, the reception ID judging unit <NUM>, the reception ID list storing unit <NUM>, the decryption processing unit <NUM>, the shared key list storing unit <NUM>, the MAC processing unit <NUM>, the session key storing unit <NUM>, the counter storing unit <NUM>, the frame generating unit <NUM>, the data acquisition unit <NUM>, and a serial ID storing unit <NUM>. These components are functional components, and the functions thereof are realized by a communication circuit in the ECU 20100a, a processor or digital circuit of the like that executes the control program stored in the memory, and so forth. The ECUs 20100b through 20100d also have basically the same configuration as the ECU 20100a. Components of the ECU 20100a that are the same as the components of the ECU 100a (see <FIG>) will be denoted with the same reference numerals, and description will be omitted here.

The serial ID storing unit <NUM> stores a serial ID that is an ID unique to the ECU 20100a.

The frame generating unit <NUM> acquires a serial ID that the serial ID storing unit <NUM> stores when generating a serial ID notification frame. The frame generating unit <NUM> generates a serial ID notification frame including the acquired serial ID and a MAC value generated by the MAC processing unit <NUM> corresponding to that serial ID, in the data field.

The ECU 20100a has a function of causing the frame generating unit <NUM> to generate a serial ID notification frame, and of transmitting the serial ID notification frame, in a case where a serial ID inquiry frame has been received from the master ECU <NUM>.

The following is a description of operations of the master ECU <NUM> inspecting the security state relating to shared keys, by confirmation of the serial ID, with reference to <FIG>.

<FIG> illustrates an example of a shared key verification sequence by the master ECU <NUM>, the ECU 20100a, the ECU 20100b, the ECU 20100c, and the ECU 20100d. Note that this shared key verification sequence is executed when the vehicle in which is installed the onboard network system <NUM> is in a particular state (e.g., a stopped state before driving), for example. As for a specific example, this is executed immediately after entering the accessory-on (ACC-ON) state.

The master ECU <NUM> transmits a frame for inquiry of serial IDs that the ECUs have (step S2101). Thus, the serial ID inquiry frame appears on the bus <NUM>.

The ECUs 20100a through 20100d each receive the serial ID inquiry frame from the bus <NUM>, and transmit a serial ID notification frame including data in the data field where a MAC has been attached to the serial ID that each stores (step S2102). That is to say, the ECU 20100a, ECU 20100b, ECU 20100c, and ECU 20100d respectively transmit serial ID notification frames to which are attached CAN-IDs "<NUM>", "<NUM>", "<NUM>", "<NUM>". Thus, the serial ID notification frames sequentially appear on the bus <NUM>.

With regard to the serial ID notification frames sequentially appearing on the bus <NUM>, the master ECU <NUM> verifies the MAC value included in each serial ID notification frame, and matches the serial ID included in the serial ID notification frame with the serial ID in the shared key list stored in the shared key list storing unit <NUM>, thereby determining whether or not the correlation between the shared key and serial ID has been changed (step S2103). Specifically, in a case where the CAN-ID of the serial ID notification frame is "<NUM>" for example, the CAN-ID "<NUM>" identified by subtracting or the like a particular value corresponding to the "<NUM>", and the corresponding serial ID in the shared key list, are identified, the serial ID and the serial ID included in the serial ID notification frame are compared, and if the serial IDs match (the correlation between the shared key and serial ID has not been changed), determination is made that the state is normal. If these do not match, determination is made that this is an error.

In a case where the results of the determination in step S2103 are not normal, the master ECU <NUM> transmits a message (frame) notifying an error (step S2104). When a message notifying an error is flowing on the bus <NUM>, a particular ECU receives this, and the particular ECU performs error notification (generating a sound indicating an error, an error display, lighting an error lamp, etc.). Note that the master ECU <NUM> may transmit a message and relegate error processing to another ECU, or may display the error on the display device, may save information relating to the error in a log, and may notify an external server of the error. In a case where determination is made of an error, the master ECU <NUM> may keep session keys from being transmitted.

In the onboard network system according to the second embodiment, the master ECU <NUM> (a first-type ECU serving as a key managing device so as to speak) confirms (inspects) the serial ID of the shared keys that the ECUs (second-type ECU) store, in a case where the vehicle Is in a particular state, such as a stopped state, and confirm that an ECU with an unauthorizedly copied shared key or the like has not been added. Accordingly, confirming the serial ID enables verification of the security state of the shared keys, i.e., enables confirmation of whether or not the risk of leakage of the shared keys that the ECUs store has increased. That is to say, a first-type ECU receives a frame including information indicating the serial ID from a second-type ECU, and distinguishes whether or not the security state of the shared key is suitable based on the serial ID and predetermined matching information stored beforehand (e.g., a shared key list), and performs communication to give the second-type ECU a session key in a case where the security state of the shared key is suitable, while performing control such as notification or the like in a case where the security state of the shared key is not suitable. Performing the shared key security state inspection in a stopped state before the vehicle drives, such as at the time of ACC-ON, and avoiding increased processing load on the ECUs and increased traffic on the bus <NUM> while the vehicle is driving, is useful. As for a method of the first-type ECU distinguishing whether or not the security state of the shared key is suitable based on the serial ID received from the second-type ECU and the matching information (shared key list or the like), the serial ID may be directly compared with the matching information to distinguish whether matching or not, or the result of having performed predetermined computation on the serial ID may be compared with the matching information.

The onboard network system including a master ECU <NUM> (key managing device) which is a partial modification of the above-described master ECU <NUM> will be described below.

The master ECU <NUM> is basically the same as the master ECU <NUM>, but the method of verifying the serial ID that the ECUs store differs. That is to say, the master ECU <NUM> has a function of verifying the serial IDs of the ECUs by communication with a server that is external from the onboard network system (outside of the vehicle). This server is a computer that manages information correlating CAN-IDs and the serial IDs of each of the ECUs.

<FIG> is a configuration diagram of the master ECU <NUM>. The master ECU <NUM> includes the frame transmission/reception unit <NUM>, the frame analyzing unit <NUM>. the reception ID judging unit <NUM>, the reception ID list storing unit <NUM>, the MAC processing unit <NUM>, the counter storing unit <NUM>, the session key list storing unit <NUM>, the encryption processing unit <NUM>, the shared key list storing unit <NUM>, the session key generating unit <NUM>, the frame generating unit <NUM>, and a server communication unit <NUM>. These components are functional components, and the functions thereof are realized by a communication circuit in the master ECU <NUM>, a processor or digital circuit of the like that executes the control program stored in the memory, and so forth. Note that the components of the master ECU <NUM> that are the same as the components of the master ECU <NUM> or master ECU <NUM> (see <FIG> and <FIG>) are denoted by the same reference numerals, and description will be omitted as appropriate.

In a case of having succeeded in verification, as the result of verifying a MAC of a data frame at the MAC processing unit <NUM>, the frame analyzing unit <NUM> notifies the server communication unit <NUM> of the CAN-ID of the data frame and the value of the data field.

The server communication unit <NUM> has a function of communicating with an external server wirelessly. The server communication unit <NUM> correlates the CAN-IDs of all data frames received from the frame analyzing unit <NUM> and the values of the data fields, notifies the server, and receives determination results from the server. In a case where an error occurs as a result of determination, the driver is notified by displaying the content of the error on the display device, for example, In a case where the determination results at the server regarding a serial ID notification frame are an error, the master ECU <NUM> can keep transmission of session keys to the ECUs from being performed.

Note that the external server is a computer communicable with the master ECU <NUM>, and has a function of, in a case of having received from the master ECU <NUM> a CAN-ID regarding an serial ID notification frame and a value indicating the serial ID that is the value of the data field, identifying the transmission source ECU from the CAN-ID set to each ECU beforehand, and making judgment regarding whether or not the serial ID managed correlated with that ECU and the received serial ID match. In a case where these match, a determination result of normal is transmitted to the master ECU <NUM>, and if not matching, an error is transmitted.

The following is a description of operations of the master ECU <NUM> inspecting the security state relating to shared keys, with reference to <FIG>.

<FIG> illustrates an example of a shared key verification sequence by the master ECU <NUM>, the ECU 20100a, the ECU 20100b, the ECU 20100c, and the ECU 20100d. Note that this shared key verification sequence is executed when the vehicle in which is installed the onboard network system is in a particular state (e.g., a stopped state before driving), for example. As for a specific example, this is executed immediately after entering the accessory-on (ACC-ON) state. Note that processing (steps) in <FIG> that are the same as those shown in <FIG> are denoted by the same reference numerals, and description will be omitted here.

In step S2102, serial ID notification frames transmitted by the ECU 20100a, ECU 20100b, ECU 20100c, and ECU 20100d sequentially appear on the bus <NUM>.

The master ECU <NUM> transmits to the external server the CAN-IDs of the serial ID notification frames sequentially appearing on the bus <NUM> and the serial ID included in the serial ID notification frames. Confirmation is made regarding whether or not the security state of the shared keys is suitable, by whether or not the determination results returned from the server are normal (step S2203). In a case where the determination results from the server are an error, i.e., the serial ID does not match, the master ECU <NUM> notifies the driver by display of information indicating an error (information indicating that there is an unauthorized ECU, etc.) on the display device (step S2204).

In the onboard network system according to the modification of the second embodiment, the master ECU <NUM> communicates with an external server in a case where the vehicle is in a particular state such as a stopped state or the like, and causes the server to determine whether the serial IDs that the ECUs store are suitable, thereby verifying whether or not the security state of the shared keys is appropriate. In a case where the configuration of the onboard network system has been changed to where the correlation between the ECU and the serial ID managed by the server differs, such as in a case where an unauthorized ECU with an unauthorizedty copied shared key is connected to the onboard network system, this is determined to be an error by the server. In a case where the security state is inappropriate, safety can be secured by notification and the like. The external server can collect information of the serial IDs of the ECUs from the master ECU <NUM> in the onboard network system and confirm the integrity, so the security state of the shared keys can be determined more appropriately.

As an embodiment of the present invention, an onboard network system will be described including a master ECU (key managing device) <NUM> that inspects the security state of the shared key by confirming the order of responses from the ECUs as to a survival confirmation frame. The onboard network system according to the present embodiment has the master ECU <NUM> in the onboard network system <NUM> according to the first embodiment (see <FIG>) replaced with the master ECU <NUM> (described later), and the ECUs 100a through 100d replaced with the ECUs 20100a through 20100d.

In the same way as the master ECU <NUM>, the master ECU <NUM> is connected to the bus <NUM>, as a type of ECU serving as a key managing device. The master ECU <NUM> stores a shared key shared with one or more ECUs out of the multiple ECUs connected to the bus <NUM> besides itself, to use for transmitting session keys mutually between the one or more ECUs for encryption processing relating to frames (including MAC processing), and functions to manage the security state of the shared key. The master ECU <NUM> transmits a survival confirmation frame requesting each ECU to transmit information (response), stores the order in which the response of each ECU has been received, and compares the order of having received the responses in accordance with the state of the vehicle, thereby inspecting the security state of the shared key. Description will be made here where a serial ID notification frame including a serial ID is transmitted, as an example of transmission of information from each ECU as a response to the survival confirmation frame.

<FIG> is a configuration diagram of the master ECU <NUM>. As illustrated in the drawing, the master ECU <NUM> includes the frame transmission/reception unit <NUM>, the frame analyzing unit <NUM>, the reception ID judging unit <NUM>, the reception ID list storing unit <NUM>, the MAC processing unit <NUM>, the counter storing unit <NUM>, the session key list storing unit <NUM>, the encryption processing unit <NUM>, the shared key list storing unit <NUM>, the session key generating unit <NUM>, the frame generating unit <NUM>, a sequence verifying unit <NUM>, and a sequence recording unit <NUM>. Note that the components that are the same as those shown in the first and second embodiments are denoted by the same reference numerals, and description will be omitted as appropriate.

The reception ID list that the reception ID list storing unit <NUM> stores includes CAN-IDs of serial ID notification frames of the ECUs, as shown in the second embodiment.

In a case of having succeeded in verification as a result of the verification of the MAC of the data frame in the MAC processing unit <NUM>, the frame analyzing unit <NUM> notifies the sequence verifying unit <NUM> of the CAN-ID of that data frame and the value of the data field.

The sequence verifying unit <NUM> acquires from the frame analyzing unit <NUM> a set of CAN-ID and data field value regarding a serial ID notification frame identified by the CAN-ID, received as a response to a first survival confirmation frame, and records this as a sequence recording list by notifying the sets in the order of acquisition to the sequence recording unit <NUM>. The sequence verifying unit <NUM> reads out from the sequence recording unit <NUM> the sequence recording list where the sets of CAN-ID and data field value recorded the previous time have been ordered, and confirms whether or not this matches the order of the sets acquired from the frame analyzing unit <NUM>. In a case where the order of receipt of serial ID notification frames form the ECUs as responses to the survival confirmation frame differ between the previous time and this time, the sequence verifying unit <NUM> performs error processing such as displaying an error on the display device. Besides displaying an error, other examples or error processing may include recording in a log, keeping session keys from being transmitted to the ECUs, and so forth. The sequence verifying unit <NUM> may further confirm the serial IDs based on the shared key list stored in the shared key list storing unit <NUM>, as with the list confirmation unit <NUM> in the second embodiment, for example.

The sequence recording unit <NUM> records the set of CAN-ID and data field value as a sequence recording list, in the order of notification. Note that this may recorded with only the CAN-ID correlated with the order (number). In this case, the sequence verifying unit <NUM> notifies the received CAN-IDs n the order of reception to the sequence recording unit <NUM> so as to be recorded, and confirms whether or not the order of the CAN-IDs received this time matches the order of CAN-IDs recorded the previous time.

<FIG> illustrates an example of a sequence recording list. The example in this drawing indicates that serial ID notification frames have been transmitted in the order of CAN-IDs "<NUM>", "<NUM>", "<NUM>", and "<NUM>". as responses to the previous survival confirmation frame.

The following is a description of operations of the master ECU <NUM> inspecting the security state relating to shared keys, by confirmation of the order of responses from the ECUs to the survival confirmation frame, with reference to <FIG>.

<FIG> Illustrates an example of a shared key verification sequence by the master ECU <NUM>, the ECU 20100a, the ECU 20100b, the ECU 20100c, and the ECU 20100d. Note that this shared key verification sequence is executed when the vehicle in which is installed the onboard network system is in a particular state (e.g., a stopped state before driving), for example. As for a specific example, this is executed immediately after entering the accessory-on (ACC-ON) state and immediately after entering the accessory-off (ACC-OFF) state.

The master ECU <NUM> transmits a survival confirmation frame to each of the ECUs (step S3101). Thus, the survival confirmation frame appears on the bus <NUM>.

The ECUs 20100a through 20100d each receive the survival confirmation frame from the bus <NUM>, and transmit a serial ID notification frame including data in the data field where a MAC has been attached to the serial ID that each stores (step S3102). After having received the survival confirmation frame, the ECUs each standby for a standby time unique to each ECU, and then transmit the serial ID notification frame as a response to the survival confirmation frame. In the example in <FIG>, the ECU 20100a, ECU 20100b, ECU 20100c, and ECU 20100d respectively transmit serial ID notification frames to which are attached CAN-IDs "<NUM>", "<NUM>", "<NUM>", "<NUM>", in that order. Thus, the serial ID notification frames sequentially appear on the bus <NUM>.

With regard to the serial ID notification frames sequentially appearing on the bus <NUM>, the master ECU <NUM> records the CAN-IDs of the serial ID notification frames as a sequence recording list in the order of reception (step S3103). The master ECU <NUM> compares the order of reception of CAN-IDs that are the responses this time with the order of reception the previous time, based on the record of CAN-ID reception order relating to responses obtained at the time of having transmitted the survival confirmation frame the previous time (the sequence recording list recorded the previous time), and distinguishes whether or not the order of reception is the same as the previous time (step S3104). If not the same, an error is displayed on the display device (step S3105). Note that in step S3104 the master ECU <NUM> may determine not only the order of reception, but further whether or not the set of serial IDs acquired from the received CAN-ID and data field are the same as the previous time. Besides displaying an error on the display device in step S3105, the error may be recorded in a log, notified to an external server, a message (frame) notifying the error may be transmitted, or the like. When a message notifying an error is flowing on the bus <NUM>, a particular ECU may receive this, and the particular ECU may perform error notification (generating a sound indicating an error, an error display, lighting an error lamp, etc.).

In the onboard network system according to the third embodiment, in a state where the vehicle is in a particular state, such as in a stopped state or the like, the master ECU <NUM> (a first-type ECU serving as a key managing device so as to speak) transmits a survival confirmation frame as a request to the ECU 20100a, ECU 20100b. ECU 20100c, and ECU 20100d, (second-type ECUs), and confirms the order in which responses as responses to this request (serial ID notification frames) appear on the bus <NUM>, and thus can confirm whether the configuration of the onboard network system has been changed. That is to say, the first-type ECU confirms (inspects) the order of responses by distinguishing whether the CAN-IDs have been received in the order of a predetermined order list (e.g., the sequence recording list recorded the previous time), based on the CAN-IDs of the frames sequentially received from the multiple second-type ECUs after having transmitted the frame indicating a predetermined request (e.g., survival confirmation frame). Accordingly, confirming the response order enables verification of the security state of the shared keys, and safety can be secured by notification or the like in a case where the security state is unsuitable. Performing the shared key security state inspection in a stopped state such as at the time of ACC-ON and ACC-OFF, avoiding increased processing load on the ECUs and increased traffic on the bus <NUM> while the vehicle is driving, is useful.

The master ECU <NUM> is basically the same as the master ECU <NUM>, but the method of confirming the order of responses that the ECUs return after having transmitted the survival confirmation frame as a request differs. That is to say, the master ECU <NUM> has a function of confirming the order of responses (serial ID notification frames) received from the ECUs by communication with a server that is external from the onboard network system (outside of the vehicle). This server is a computer that manages information indicating the order of CAN-IDs in the serial ID notification frames transmitted as responses to the survival confirmation frame.

<FIG> is a configuration diagram of the master ECU <NUM>. The master ECU <NUM> includes the frame transmission/reception unit <NUM>, the frame analyzing unit <NUM>, the reception ID judging unit <NUM>, the reception ID list storing unit <NUM>, the MAC processing unit <NUM>, the counter storing unit <NUM>, the session key list storing unit <NUM>, the encryption processing unit <NUM>, the shared key list storing unit <NUM>, the session key generating unit <NUM>, the frame generating unit <NUM>, and a server communication unit <NUM>. These components are functional components, and the functions thereof are realized by a communication circuit in the master ECU <NUM>, a processor or digital circuit of the like that executes the program stored in the memory, and so forth. Note that the components of the master ECU <NUM> that are the same as the components of the master ECU <NUM> and master ECU <NUM> (see <FIG> and <FIG>) are denoted by the same reference numerals, and description will be omitted as appropriate.

In a case of having succeeded in verification, as the result of verifying a MAC of a data frame at the MAC processing unit <NUM>, the frame analyzing unit <NUM> notifies the server communication unit <NUM> of the CAN-ID of the data frame and the value of the data field.

The server communication unit <NUM> has a function of communicating with an external server wirelessly. The server communication unit <NUM> correlates the CAN-IDs of all data frames received from the frame analyzing unit <NUM> and the values of the data fields, notifies the server, and receives determination results from the server. In a case where an error occurs as a result of determination, the driver is notified by displaying the content of the error on the display device, for example. In a case where the determination results at the server regarding the order of serial ID notification frames transmitted from the ECUs as responses to the survival confirmation frame as a request are an error, the master ECU <NUM> can display an error, record in a log, or the like. Also, in a case of an error, the master ECU <NUM> can keep transmission of session keys to the ECUs from being performed.

Note that the external server is a computer communicable with the master ECU <NUM>, and has a function of, in a case of having received from the master ECU <NUM> a series of CAN-IDs and values indicating serial IDs that are data field values, regarding serial ID notification frames, recording and managing the CAN-IDs and serial IDs predetermined to each transmission source ECU, in the order of serial ID reception, and comparing with the contents serially received and recorded the previous time. In a case where the comparison shows that the serial ID notification frames serially received match the contents recorded the previous time (i.e., a case where the order of CAN-IDs matches, and also the combination with serial IDs also matches), a determination result of normal is transmitted to the master ECU <NUM>, and if not matching, an error is transmitted.

<FIG> illustrates an example of a shared key verification sequence by the master ECU <NUM>, the ECU 20100a, the ECU 20100b, the ECU 20100c, and the ECU 20100d. Note that this shared key verification sequence is executed when the vehicle in which is installed the onboard network system is in a particular state (e.g., a stopped state before driving), for example. As for a specific example, this is executed immediately after entering the accessory-on (ACC-ON) state and immediately after entering the accessory-off (ACC-OFF) state. Note that processing (steps) in <FIG> that are the same as those shown in <FIG> are denoted by the same reference numerals, and description will be omitted here.

In step S3102, serial ID notification frames transmitted by the ECU 20100a, ECU 20100b, ECU 20100c, and ECU 20100d as responses to the survival confirmation frame sequentially appear on the bus <NUM>.

The master ECU <NUM> consecutively transmits to the server the sets of CAN-IDs of the serial ID notification frames consecutively and sequentially appearing on the bus <NUM> and the values included in the serial ID notification frames. Whether or not the security state of the shared keys is suitable is inspected, by whether or not the determination results returned from the server are normal (step S3203). In a case where the determination results from the server are an error, i.e., the order of responses from the ECUs as to the survival confirmation frame does not match the order of responses as to the survival confirmation frame the previous time, or the contents of the responses (serial IDs) do not match the previous time, and accordingly the security state of the shared key is in appropriate, the master ECU <NUM> notifies the driver by display of information indicating an error (information indicating that there is an unauthorized ECU, etc.) on the display device (step S3204).

In the onboard network system according to the modification of the third embodiment, the master ECU <NUM> communicates with an external server in a case where the vehicle is in a particular state such as a stopped state or the like, and causes the server to determine whether the order of frames that the ECUs transmit is suitable, thereby verifying whether or not the security state of the shared keys is appropriate. In a case where the configuration of the onboard network system has been changed, the order of frames transmitted by the ECUs changes as compared to before, so this is determined to be an error by the server. In a case where the security state is inappropriate (a case where determination of an error has been made), safety can be secured by notification and the like. The external server can collect information of the serial IDs of the ECUs from the master ECU <NUM> in the onboard network system installed in each of multiple vehicles and confirm the integrity, so the security state of the shared keys can be inspected more appropriately.

The first through third embodiments have been described above as examples of the technology according to the present invention. However, the technology according to the present invention is not restricted to this, and embodiments where modifications, substitutions, addition, omission, and so forth have been performed as appropriate are also applicable. For example, the following modifications are also included as an embodiment.

Claim 1:
A key management method in a first-type electronic control unit (<NUM>) out of a plurality of electronic control units (ECUs) in an onboard network system (<NUM>) installed in a vehicle, the onboard network system (<NUM>) having the plurality of electronic control units (ECUs) that perform communication by frames via a network of the onboard network system (<NUM>), the method comprising:
storing a shared key to be mutually shared with one or more second-type electronic control units (100a-100d) other than the first-type electronic control unit (<NUM>), for transmission of a session key used for encryption relating to a frame transmitted or received via the network, the shared key also being stored in the one or more second-type electronic control units (100a-100d) other than the first-type electronic control unit (<NUM>);
characterised by skipping inspection of a security state of the shared key stored by driving system electronic control units (100a) related to driving, out of the one or more second-type electronic control units (100a-100d) other than the first-type electronic control unit (<NUM>), and executing inspection of a security state of the shared key stored by the second-type electronic control units (100b-100d) other than the driving system electronic control units (100a) , in a state where the vehicle is driving.