COMMUNICATION SYSTEM, VEHICLE, AND MONITORING METHOD

A communication system includes a first electronic device, and a second electronic device that monitors a state of the first electronic device. The first electronic device includes a transmitter that transmits a first frame including a first verification value forming a Hash chain to a bus network. The second electronic device includes a storage unit that stores the first verification value included in the first frame received from the bus network. The transmitter transmits, after transmission of the first frame, a second frame including a second verification value forming the Hash chain to the bus network. The second electronic device further includes a determination unit that determines that the state of the first electronic device is normal when the second verification value included in the second frame received from the bus network and the first verification value stored in the storage unit construct the Hash chain.

The present application claims the benefit of foreign priority of Japanese patent application 2017-027281 filed on Feb. 16, 2017, the contents all of which are incorporated herein by reference.

BACKGROUND

1. Technical Field

The present disclosure relates to a data processing technique, and particularly relates to a communication system, a vehicle, and a monitoring method.

2. Description of the Related Art

In recent years, a vehicle is mounted with a lot of electronic control units (hereinafter referred to as ECUs). A network that connects these ECUs is called an in-vehicle network. Many standards are present for the in-vehicle network, and among them a controller area network (CAN) is widely used.

A CAN communication system that protects data transmitted/received through the CAN with a message authentication code (hereinafter referred to as MAC) is proposed (for example, see Unexamined Japanese Patent Publication No. 2013-48374).

SUMMARY

The present disclosure provides a technique that provides preferable message authentication.

A communication system from one aspect of the present disclosure includes a first electronic device connected to a bus network, and a second electronic device that is connected to the bus network and monitors a state of the first electronic device. The first electronic device includes a transmitter that transmits a first frame including a first verification value forming a Hash chain to the bus network. The second electronic device includes a storage unit that stores the first verification value included in the first frame received from the bus network. The transmitter of the first electronic device transmits, after transmission of the first frame, a second frame including a second verification value forming the Hash chain to the bus network. The second electronic device further includes a determination unit that determines that the state of the first electronic device is normal when the second verification value included in the second frame received from the bus network and the first verification value stored in the storage unit construct the Hash chain.

A vehicle from another aspect of the present disclosure includes a first electronic device connected to an in-vehicle bus network, and a second electronic device that is connected to the in-vehicle bus network and monitors a state of the first electronic device. The first electronic device includes a transmitter that transmits a first frame including a first verification value forming a Hash chain to the in-vehicle bus network. The second electronic device includes a storage unit that stores the first verification value included in the first frame received from the in-vehicle bus network. The transmitter of the first electronic device transmits, after transmission of the first frame, a second frame including a second verification value forming the Hash chain to the in-vehicle bus network. The second electronic device further includes a determination unit that determines that the state of the first electronic device is normal when the second verification value included in the second frame received from the in-vehicle bus network and the first verification value stored in the storage unit construct the Hash chain.

A monitoring method from still another aspect of the present disclosure includes a first electronic device transmitting a first frame including a first verification value forming a Hash chain to an in-vehicle bus network. The first electronic device is connected to the in-vehicle bus network. Further, the monitoring method includes a second electronic device storing the first verification value included in the first frame received from the in-vehicle bus network into a storage unit. The second electronic device is connected to the in-vehicle bus network and monitors a state of the first electronic device. The monitoring method further includes the first electronic device transmitting, after the transmitting of the first frame, a second frame including a second verification value forming the Hash chain to the in-vehicle bus network. Further, the monitoring method includes the second electronic device determining that the state of the first electronic device is normal when the second verification value included in the second frame received from the in-vehicle bus network and the first verification value stored in the storage unit construct the Hash chain.

Any desired combinations of the above described components and modifications of the features of the present disclosure in devices, computer programs, recording media containing the computer programs, or other entities are still effective as other aspects of the present disclosure.

The present disclosure can provide suitable message authentication.

DETAILED DESCRIPTION

Prior to describing an exemplary embodiment of the present disclosure, problems found in a conventional technique will now be briefly described herein. In order to identify an electronic control unit (ECU) which transmits invalid message in a system that performs message authentication using a message authentication code (MAC), different keys need to be set for each pair of respective ECUs. Therefore, a key management cost is high.

Prior to describing a configuration according to the exemplary embodiment, an outline will be described. In the message authentication using the MAC described in Unexamined Japanese Patent Publication No. 2013-48374, an ECU which transmits an invalid message cannot be identified if different keys are not set for each pair of ECUs. Further, the message authentication using the MAC is comparatively light, but a cost for key maintenance is high.

Further, Unexamined Japanese Patent Publication No. 2014-146868 proposes a network apparatus that monitors periodic information about a message being sent through a network and detects presence of an invalid message. However, it is difficult to discriminate a valid message and an invalid message and accurately specify the invalid message, by monitoring using only the periodic information.

Therefore, a monitoring ECU according to the exemplary embodiment authenticates validity of a message transmitted from an inspection target ECU to be monitored based on a Hash chain. As a result, a normal message and an abnormal message can be discriminated with high accuracy without using key information.

FIGS. 1 and 17illustrate a configuration of vehicle10according to the exemplary embodiment. As illustrated inFIG. 17, vehicle10includes main body109and driver104that moves main body109. Driver104includes drive source105such as an engine or a motor, and drive wheels106driven by drive source105.FIG. 1illustrates the configuration of vehicle10according to the exemplary embodiment. Vehicle10includes inspection target ECU12a, inspection target ECU12b, inspection target ECU12c, and inspection target ECU12d (collectively referred to as “inspection target ECU12”), monitoring ECU14, and central gateway (CGW)17. Respective devices inFIG. 1are connected via a controller area network (CAN)16which is an in-vehicle bus network to configure in-vehicle network system18.

Inspection target ECU12is an ECU whose normality is inspected. The plurality of inspection target ECUs12may be, for example, an engine ECU, a brake ECU, a steering ECU, or a transmission ECU. Each inspection target ECU12is connected to a sensor, not illustrated, and outputs a message, which includes detection information from the sensor (also referred to as a “frame” or a “packet”, and hereinafter referred to as a “frame”), to a bus of CAN16. Alternatively, each inspection target ECU12is connected to an actuator, not illustrated, and outputs a frame, which includes information about control over the actuator, to the bus of CAN16. Details of a function of inspection target ECU12will be described later. For example, an engine ECU controls drive source105such as an engine or a motor.

Monitoring ECU14monitors, based on a predetermined monitoring rule, normality of a frame which is being sent through the bus of CAN16to monitor normality (in other words, validity) of each of the plurality of inspection target ECUs12. Monitoring ECU14may be mounted as a dedicated device. Further, a monitoring module including a function of monitoring ECU14may be incorporated into an existing ECU (for example, an ECU of the CGW). Details of a function of monitoring ECU14will be described later.

In the exemplary embodiment, inspection target ECU12is connected to a first bus of CAN16, and monitoring ECU14is connected to a second bus of CAN16. CGW17relays a frame between a plurality of buses including the first bus and the second bus. CGW17may remove a frame having predetermined identifier (ID) at a predetermined rate for adjustment of traffic. For example, CGW17may relay frames, which are sent through the first bus in a cycle of50milliseconds, to the second bus every other time. In other words, the traffic may be adjusted by discarding a frame every other time without relay so that the cycle of the frames in the second bus is100milliseconds. It is not required that the first bus and the second buts are separated from each other. Inspection target ECU12and monitoring ECU14may be connected to one bus.

FIG. 2is a block diagram illustrating a functional configuration of inspection target ECU12illustrated inFIG. 1. Inspection target ECU12includes communication unit20, random number generation unit22, authenticator generation unit24, commitment storage unit26, and frame generation unit28.

Blocks illustrated in the block diagrams of this specification can be achieved by, in terms of hardware, a central processing unit (CPU) of a computer and elements including a memory and a machine device, and in terms of software, by computer programs and other programs. Herein, functional blocks realized by cooperation of these are illustrated. It will be understood by those skilled in the art that these functional blocks can be achieved in various forms through combinations of hardware and software. For example, computer programs including modules related to the respective blocks inFIG. 2may be stored in a memory of inspection target ECU12. Functions of the respective blocks may be fulfilled in a manner that the CPU of inspection target ECU12appropriately executes the computer programs. Further, as another example, these functional blocks can also be realized as a physical circuit such as a dedicated integrated circuit (IC), a large-scale integration (LSI) circuit. The same is true on monitoring ECU14which will be described later with reference toFIG. 6.

Communication unit20receives a frame from a bus of CAN16in accordance with a CAN protocol. Further, communication unit20outputs a frame generated by frame generation unit28to the bus of CAN16.

Random number generation unit22generates a random number sequence, which serves as original data of a Hash chain. Random number generation unit22may generate a random number sequence using a hardware random number generator. Further, random number generation unit22may generate a pseudo random number sequence through software calculation. In random number generation unit22, accuracy can be secured by saving seeds of the random numbers in a storage. Further, random number generation unit22may generate a plurality of random number sequences respectively to generate a new random number sequence based on the plurality of random number sequences. This can increase entropy.

When the frame received by communication unit20is a commitment request frame (a frame having an ID of the commitment request frame), authenticator generation unit24generates an authenticator for authenticating a Hash chain, based on the random number sequence generated by random number generation unit22. Further, when commitment updating timing comes, authenticator generation unit24generates a new authenticator based on the new random number sequence generated by random number generation unit22. Authenticator generation unit24stores data of the generated authenticator in commitment storage unit26.

FIG. 3illustrates a procedure for generating an authenticator. First, authenticator generation unit24inputs data obtained by combining a time value (Time), an ID, and a random number sequence (random number R) into a predetermined Hash function to obtain Hash value1output from the Hash function. Authenticator generation unit24truncates Hash value1based on a predetermined rule to obtain authenticator1.

When registration of a commitment is requested from monitoring ECU14, authenticator generation unit24uses a time value notified by monitoring ECU14as the time value inFIG. 3. On the other hand, when the commitment is voluntarily updated, authenticator generation unit24obtains a time value indicating a current time from an operating system (OS) of inspection target ECU12to use the time value. The time value is used as a parameter for generating an authenticator to prevent a retransmission attack. Therefore, if data has a property such that a counter value fluctuates (for example, increases), such data other than the time value can be used. Further, as the ID inFIG. 3, authenticator generation unit24uses a frame ID (also referred to as a message ID) which is set in a normal frame to be inspected. Further, a truncation rule may be such that higher-order or lower-order N bits (for example, 8 bits, 12 bits, 16 bits, etc.) of a Hash value are extracted.

Thereafter, authenticator generation unit24inputs data, which is obtained by combining authenticator1with a time value and an ID which are identical to the time value and ID at the time of generating Hash value1, into the Hash function to obtain Hash value2. Authenticator generation unit24truncates Hash value2based on the above-described rule to obtain authenticator2. In the exemplary embodiment, an ID and a time value are synthesized with a random number or an authenticator, a Hash value of the synthesized data is obtained, and the Hash value is truncated so that a next-stage authenticator is obtained. This is one Hash operation. Authenticator generation unit24constructs a Hash chain by repeating the Hash operation at a predetermined number of times (for example, 999 times), and generates a plurality of authenticators (for example, authenticator1, authenticator2, . . . authenticator999) in the Hash chain.

The Hash values on middle portions may possibly be identical to one other among the plurality of inspection target ECUs12. However, since one parameter includes an ID in the Hash operation each time, even if the Hash values are once identical to one other, the Hash values thereafter are more likely to be different. In a modification, the time value and the ID inFIG. 3may be replaced by fixed padding character strings predetermined between inspection target ECU12and monitoring ECU14.

Back toFIG. 2, commitment storage unit26stores an authenticator generated by authenticator generation unit24.FIG. 4schematically illustrates data stored in commitment storage unit26. Commitment storage unit26stores a plurality of authenticators generated by the Hash operation performed by authenticator generation unit24at a plural number of times, namely, stores authenticator (0) to authenticator (999). Authenticator (0) inFIG. 4is a random number sequence generated by random number generation unit22. Further, authenticator (999) inFIG. 4is the last authenticator generated through999Hash operations, and is registered as a commitment in monitoring ECU14.

First, frame generation unit28generates a commitment registration frame including the data of a commitment (inFIG. 4, authenticator (999)) stored in commitment storage unit26. Frame generation unit28outputs the commitment registration frame to communication unit20, and communication unit20transmits the commitment registration frame to monitoring ECU14.

Thereafter, frame generation unit28stores identification information (a position, etc.) about a used authenticator in the authenticators stored in commitment storage unit26. The used authenticator is, for example, an authenticator that has been set in a commitment registration frame or a normal frame. As a modification, frame generation unit28may store identification information about an unused authenticator. The unused authenticator is, for example, an authenticator that has not been set in the frame. In the exemplary embodiment, frame generation unit28stores identification information (herein, N) about the last authenticator used.

In a case where data to be delivered to an external device (another ECU or the like) such as detection information of a sensor or control information of an actuator is generated, frame generation unit28generates a frame including the data (hereinafter, also referred to as a “normal frame”). Frame generation unit28sets authenticator (N−1) in the normal frame. Authenticator (N−1) is an authenticator that is adjacent to the last authenticator used (authenticator(N)) in the unused authenticators. Frame generation unit28outputs the generated normal frame to communication unit20, and communication unit20performs broadcast transmission of the normal frame to CAN16.

FIG. 5AtoFIG. 5Eillustrate examples of frames to be output form inspection target ECU12. Herein, inspection target ECU12generates authenticator (0) to authenticator (999), and when using authenticators (1) to (10), reregisters a commitment based on a new Hash chain in monitoring ECU14.

FIG. 5Aillustrates a commitment registration frame. The commitment registration frame includes a frame ID of a frame to be inspected by using a commitment to be registered, a time value, an authenticator due to an earlier Hash chain (old authenticator (9)), and an authenticator due to a new Hash chain (authenticator (999)). At a time of first commitment registration, a default value (for example, “0000 . . . ”) is set in a field of an authenticator due to an earlier Hash chain.

FIG. 5B,FIG. 5C, andFIG. 5Dillustrates a normal frame. The normal frame includes an ID, an authenticator, and a message text (simply, “data”) of the frame.FIG. 5Billustrates a normal frame to be transmitted next after a commitment registration frame and includes authenticator (998).FIG. 5Cillustrates a normal frame to be transmitted next after the normal frame inFIG. 5Band includes authenticator (997).FIG. 5Dillustrates a 990th normal frame to be transmitted and includes authenticator (10).

FIG. 5Eillustrates a commitment registration frame. This commitment registration frame is transmitted next after the normal frame inFIG. 5Dand is for registering a new commitment (new authenticator (999)) based on a new Hash chain. Further, the commitment registration frame inFIG. 5Eincludes the ID identical to the commitment registration frame inFIG. 5A, a time value different fromFIG. 5A, and old authenticator (9) which is old authenticator (N−1).

FIG. 6is a block diagram illustrating a functional configuration of monitoring ECU14illustrated inFIG. 1. Monitoring ECU14includes communication unit30, commitment registration unit32, commitment storage unit34, monitoring unit36, and abnormality processor42. Monitoring unit36includes determination unit38and commitment updating unit40.

Communication unit20receives a frame from a bus of CAN16in accordance with a CAN protocol. Further, communication unit30outputs a frame generated by monitoring ECU14to the bus of CAN16.

When a predetermined condition is satisfied, for example, when monitoring ECU14is powered on, commitment registration unit32generates a commitment request frame which is a frame for requesting commitment registration. Commitment registration unit32outputs the commitment request frame to communication unit30, and communication unit30performs broadcast transmission of the commitment request frame to CAN16.

Further, when the frame received by communication unit30is a commitment registration frame (a frame having an ID of the commitment registration frame), commitment registration unit32saves data included in the commitment registration frame (for example, authenticator (999)) in commitment storage unit34.

Commitment storage unit34stores a commitment management table.FIG. 7illustrates the commitment management table. Commitment management table may be a table and includes a frame ID, an ECU-ID, a cycle, a number of operation times, a time stamp, a bit length, a commitment, and an authentication algorithm as a plurality of parameters. The frame ID represents an ID of a normal frame to be inspected (a message ID). The ECU-ID represents an ID of inspection target ECU12which is a transmission source of a normal frame. The cycle is a parameter for detecting a behavior and represents a frame reception cycle. The number of operation times represents a number of times of a Hash operation in Hash chain authentication.

The time stamp is a parameter for a countermeasure against a retransmission attack using a commitment registration frame. The bit length represents a bit length of a commitment. The authentication algorithm represents an algorithm for authenticating a normal frame. The authentication algorithm includes, for example, backward Hash, forward Hash, a MAC, or a combination of them. An amount of calculation resource of the plurality of inspection target ECUs12varies, and an authentication algorithm according to the amount of calculation resource can be used. As described later, a combination of the Hash chain authentication and the MAC authentication makes it possible to understand details of an abnormal state of inspection target ECU12.

In the parameters in the commitment management table, the frame ID, the ECU-ID, the cycle, the number of operation times, and authentication algorithm are preset at a time of manufacturing vehicle10. Alternatively, the commitment management table in which these parameter values are set may be provided from a server on a cloud to vehicle10. It is preferable that an electronic signature of a manufacturer is provided to the commitment management table provided by the server, and only a management table whose authentication has succeeded is accepted. Commitment registration unit32specifies a record of the commitment management table related to the frame ID of the normal frame set in the commitment registration frame (hereinafter referred to as “correspondence rule”), and sets a time value, which is included in the commitment registration frame, in a field of the time stamp of the correspondence rule. Further, commitment registration unit32sets a commitment value, which is included in the commitment registration frame (for example, authenticator (999)), in the field of the commitment of the correspondence rule, and sets a length of the commitment in the field of the bit length.

When the time value included in the commitment registration frame is older than or equal to the time stamp of the correspondence rule in the commitment management table, commitment registration unit32determines that the commitment registration frame is a retransmission attack, and discards the commitment registration frame. That is, commitment registration unit32suppresses reflecting of contents of the commitment registration frame in the correspondence rule.

Further, when a result of the Hash operation based on a value of the old authenticator included in the commitment registration frame (for example, old authenticator(9) inFIG. 5A) matches a commitment value of the correspondence rule (a value before updating), commitment registration unit32reflects the contents of the commitment registration frame in the correspondence rule. That is, commitment registration unit32saves the commitment value included in the commitment registration frame as a new commitment value of the correspondence rule. As a result, invalid updating of the commitment value is prevented.

Back toFIG. 6, monitoring unit36monitors, based on the commitment management table stored in commitment storage unit34, validity of a frame received by communication unit30. Specifically, when the ID of the received frame has been recorded in the commitment management table in commitment storage unit34, determination unit38identifies the received frame as a frame to be inspected, and identifies a record of the commitment management table that matches the frame ID of the frame to be inspected as the correspondence rule. Determination unit38checks whether the authenticator included in the frame to be inspected and the commitment value of the correspondence rule construct a Hash chain. When both the authenticator and the commitment value construct a Hash chain, determination unit38determines that the frame to be inspected is normal, and determines that the state of inspection target ECU12which is a transmission source of the frame is normal.

Authentication based on the backward Hash will be described. In a case of the backward Hash, an Nth (N is an integer of 2 or more) authenticator in the Hash chain is prerecorded as a commitment value in the commitment management table, and an N-1st authenticator in the Hash chain is specified in a frame to be inspected. Determination unit38inputs the authenticator included in the frame to be inspected and synthesized data of the frame ID and the time stamp in the correspondence rule into the Hash function to obtain a Hash value. Determination unit38obtains a value obtained by truncating the Hash value in accordance with a predetermined truncation rule as a verification value. The Hash function and the truncation rule are shared between inspection target ECU12and monitoring ECU14.

That is, determination unit38generates authenticator (α+1) as a verification value based on an authenticator (authenticator (α)) included in a frame to be inspected. When a transmission source of the frame to be inspected is appropriate inspection target ECU12, the verification value matches the commitment value prerecorded in the commitment management table. Therefore, when the verification value matches the commitment value of the correspondence rule, determination unit38determines that the frame to be inspected is normal, and determines that the state of inspection target ECU12which is the transmission source of the frame to be inspected is normal. In other words, when the verification value does not match the commitment value of the correspondence rule, determination unit38determines that the frame to be inspected is abnormal, and determines that the state of inspection target ECU12which is the transmission source of the frame to be inspected is abnormal.

Next, authentication based on the forward Hash will be described below. In a case of the forward Hash, an Nth (N is an integer of 1 or more) authenticator in a Hash chain is prerecorded as a commitment value in the commitment management table, and an N+1st authenticator in the Hash chain is specified in the frame to be inspected. Determination unit38inputs synthesized data of the frame ID, the time stamp, and the commitment value in the correspondence rule into the Hash function to obtain a Hash value. Determination unit38obtains a value obtained by truncating the Hash value in accordance with a predetermined truncation rule as a verification value.

That is, determination unit38generates authenticator (α+1) as a verification value based on authenticator (α) which is the prerecorded commitment value. When the verification value matches an authenticator included in a frame to be inspected, determination unit38determines that the frame to be inspected is normal, and determines that the state of inspection target ECU12which is the transmission source of the frame to be inspected is normal. A security level is lower in the forward Hash than in the backward Hash, but an amount of calculation in inspection target ECU12is smaller. For this reason, the forward Hash is preferable in a case where a calculation resource of inspection target ECU12is small. For example, valid inspection target ECU12aregisters a commitment in monitoring ECU14, and accordingly continues transmitting a forward Hash chain to monitoring ECU14. In this case, even if invalid inspection target ECU12bspoofs inspection target ECU12ato transmit a frame, monitoring ECU14recognizes that two ECUs continue transmission with the same chain and thus can detect occurrence of invalidity. The combination of the Hash chain authentication and the MAC authentication will be described in modifications.

Further, determination unit38measures a reception cycle of frames having a plurality of frame IDs defined in the commitment management table. Determination unit38determines, as detection of a behavior, that a frame, in which a difference between the measured reception cycle and the cycle in the commitment management table exceeds a predetermined range, is abnormal. Further, determination unit38determines that the state of inspection target ECU12which is the transmission source of the frame is abnormal. The detection of the behavior makes it possible to detect spoofing of an ECU.

In the number of operation times in the commitment management table, a number of times is set in accordance with a number of frames to be discarded by CGW17among frames transmitted by inspection target ECU12(for example, a rate of a frame which is not relayed between buses of CAN16). For example, in the commitment management table inFIG. 7, since the frames having IDs “10”, “40”, and “50” are not discarded by CGW17, the number of operation times is set to one (namely, no repetition). On the other hand, since the frame having ID “20” is discarded by CGW17every other time (in other words, 50% of the frames are discarded), the number of operation times is set to two.

In the case of the Backward Hash, when a result of performing the Hash operation based on an authenticator included in a frame to be inspected at the number of operation times defined by the correspondence rule matches the commitment value defined by the correspondence rule, determination unit38determines that the state of inspection target ECU12which is the transmission source of the frame to be inspected is normal. On the other hand, in the case of the forward Hash, when a result of performing the Hash operation based on the commitment value of the correspondence rule at the number of operation times defined by the correspondence rule matches the authenticator included in a frame to be inspected, determination unit38determines that the state of inspection target ECU12which is the transmission source of the frame to be inspected is normal.

In an example of the commitment management table inFIG. 7, determination unit38obtains a result of repeating the Hash operation based on the authenticator included in the frame having ID “20” twice as a verification value. When the verification value matches the commitment value, determination unit38determines that the state of inspection target ECU12(ECU-2) which is the transmission source of the frame having ID “20” is normal. As a result, also when CGW17deletes a frame, in other words, reduces a band, monitoring ECU14can accurately determine normality of the frame, namely, normality of inspection target ECU12which is the frame transmission source.

When a result of performing the Hash operation based on an authenticator included in a frame to be inspected at the number of operation times defined by the correspondence rule (herein, X times) does not match the commitment value defined by the correspondence rule, determination unit38may repeat the Hash operation and collate each result of each Hash operation with the commitment value. Further, a number of retry times in the Hash operation is predetermined, and frame generation unit28may repeat the Hash operation up to a ceiling of the number of retry times. When a result of repeating the Hash operation at a certain number of times (herein, Y times) matches the commitment value, determination unit38may detect that transmission of (Y-X) frames results in error in CAN16.

For example, when a result of repeating the Hash operation on the frame having ID “10” inFIG. 7three times matches the commitment value, determination unit38may determine loss of two frames having ID “10”.

Further, when a result of repeating the Hash operation on the frame having ID “20” inFIG. 7three times matches the commitment value, determination unit38may determine loss of one frame having ID “20”. According to this aspect, deletion of a frame by CGW17and loss of a frame due to a transmission error can be discriminately detected.

After determination unit38determines whether a frame to be inspected is normal, commitment updating unit40records an authenticator included in the frame to be inspected as a new commitment value into a commitment field of the correspondence rule.

Determination unit38outputs at least one of a frame ID and an ECU-ID determined as being abnormal, and the determined result including abnormal contents to abnormality processor42. Abnormality processor42executes a post-process according to the determined result in determination unit38.

For example, abnormality processor42may record information representing the determined result in determination unit38in a predetermined log file. Further, abnormality processor42may display the information representing the determined result in determination unit38on a display unit of vehicle10(a car navigation device, a lamp of a dashboard, etc.).

Further, abnormality processor42may transmit information representing the determined result in determination unit38to a predetermined external device such as a server on a cloud. The information representing the determined result in determination unit38may include at least one of information representing whether a frame having a specific ID is normal, and information representing whether an ECU having a specific ID is normal. Further, this information may include a result of behavior detection based on a cycle or presence/absence of detection of a retransmission attack.

An operation of in-vehicle network system18having the above configuration will be described.

FIG. 8is a flowchart illustrating an operation of inspection target ECU12. If inspection target ECU12detects that commitment updating timing has come (Y in S10), inspection target ECU12executes a process for generating and registering a new commitment. The commitment updating timing comes, in the exemplary embodiment, (1) when a commitment request frame is received from monitoring ECU14, and (2) when a predetermined number of authenticators based on an earlier Hash chain are used (for example, when authenticator (999) to authenticator (10) are used). In a modification, the process for generating and registering a new commitment may be executed when another event occurs such that the power source is switched from off to on.

Random number generation unit22generates a random number, and authenticator generation unit24sets counter C to maximum value X (herein, “999”) (S12). Authenticator generation unit24repeats the Hash operation based on the random number at C times, and sequentially generates authenticator (1) to authenticator (999) to save these authenticators in commitment storage unit26(S14). Frame generation unit28generates a commitment registration frame in which authenticator (999) is set as a commitment value, and communication unit20outputs the commitment registration frame to CAN16and transmits the frame to monitoring ECU14(S16). Frame generation unit28decrements counter C (S18). Counter C indicates “998” just after the transmission of the commitment registration frame. If the commitment updating timing has not come yet (N in S10), S12to S18are skipped.

When data to be transmitted to an external device (another ECU or the like) is generated (Y in S20), frame generation unit28obtains authenticator (C) (for example, authenticator (998)) from commitment storage unit26(S22). Frame generation unit28generates a normal frame in which authenticator (C) is set, and communication unit20broadcasts the normal frame to CAN16(S24). Frame generation unit28decrements counter C (S26). When counter C indicates a value which is a predetermined threshold (for example, “9”) or less (Y in S28), the process returns to S12, and the process for generating and registering a new commitment is executed. When counter C indicates a value larger than the threshold (N in S28) and data to be transmitted remains (Y in S30), the process returns to S22. When the transmission of the data is completed (N in S30), the flow in this drawing is ended. When the data to be transmitted to an external device is not present (N in S20), S22to S30are skipped. The flow inFIG. 8is repeated during activation of inspection target ECU12.

FIG. 9is a flowchart illustrating an operation of monitoring ECU14. If commitment request timing has come as a consequence of, for example, switching the power source from off to on (Y in S40), commitment registration unit32generates a commitment request frame, and communication unit30outputs the commitment request frame to CAN16to transmit the frame to inspection target ECU12(S42). If the commitment request timing has not come yet (N in S40), S42is skipped. If communication unit20receives a frame (Y in S44) and the received frame is a commitment registration frame (Y in S46), commitment registration unit32associates a commitment value specified in the frame with an ID of a normal frame specified in the frame to save the commitment value in commitment storage unit34(S48).

If the received frame is not a commitment registration frame (N in S46) but is a frame to be inspected whose ID is registered in the commitment management table (Y in S50), determination unit38obtains an authenticator (herein, authenticator A) included in the frame to be inspected (S52). Determination unit38obtains a result of the Hash operation based on authenticator A (herein, verification value A′) (S54). Determination unit38compares the commitment value defined by the correspondence rule with verification value A′ to verify validity of verification value A′ (S56). When verification value A′ is valid, namely, verification value A′ matches the commitment value (Y in S58), determination unit38determines that the frame to be inspected is normal, namely, the state of inspection target ECU12which is the transmission source is normal. Determination unit38saves verification value A′ as a new commitment value of the correspondence rule (S60).

If verification value A′ is invalid, namely, verification value A′ does not match the commitment value (N in S58), determination unit38determines that the frame to be inspected is abnormal, namely, the state of inspection target ECU12which is the transmission source is abnormal. Abnormality processor42executes an abnormality process for a case where the state of inspection target ECU12is abnormal (for example, log output) (S62). If the received frame is not a frame to be inspected (N in S50), S52to S62are skipped, and if a frame is not received from CAN16(N in S44), S46to S62are skipped. If a predetermined condition such that power source is switched from on to off (Y in S64), monitoring ECU14ends the monitoring process in CAN16(S66) and ends the flow in this drawing. When the end condition is not satisfied (N in S64), the process returns to S40.

FIG. 10is a sequence diagram illustrating an interaction between monitoring ECU14and inspection target ECU12. Monitoring ECU14starts monitoring the bus of CAN16(S100), and transmits the commitment request frame including a time value representing a current time to inspection target ECU12(S102). Inspection target ECU12generates commitment1(authenticator (999)) based on the time value notified by a server and a random number dynamically generated (S104). Inspection target ECU12broadcasts a commitment registration frame including commitment1to CAN16so as to transmit the commitment registration frame to monitoring ECU14(S106). Monitoring ECU14stores commitment1while being associated with the ID of the normal frame transmitted by inspection target ECU12(S108).

Inspection target ECU12broadcasts, to CAN16, a normal frame which includes authenticator (998) and a message to be transmitted to an external device (S110). Monitoring ECU14receives the broadcasted normal frame as a frame to be inspected. Monitoring ECU14checks normality of the frame to be inspected by verifying authenticator (998) (S112). When the frame to be inspected is normal, monitoring ECU14updates the value of commitment1to authenticator (998) (S114). Thereafter, inspection target ECU12broadcasts, to CAN16, a normal frame, which includes authenticator (997) and a message to be transmitted to an external device (S116). Monitoring ECU14receives the broadcasted normal frame as a frame to be inspected. Monitoring ECU14checks normality of the frame to be inspected by verifying authenticator (997) (S118). When the frame to be inspected is normal, monitoring ECU14updates the value of commitment1to authenticator (997) (S120).

Thereafter, inspection target ECU12broadcasts the normal frame by sequentially using authenticator (996) to authenticator (10) until the commitment updating timing comes, and monitoring ECU14verifies the respective authenticators. When using authenticator (10), inspection target ECU12detects that the commitment updating timing has come, and generates new commitment2(authenticator (999)) based on a new Hash chain (S122). Inspection target ECU12broadcasts a commitment registration frame including commitment2to CAN16so as to transmit the commitment registration frame to monitoring ECU14(S124). Monitoring ECU14stores commitment2while being associated with the ID of the normal frame transmitted by inspection target ECU12(S126).

In in-vehicle network system18according to the exemplary embodiment, monitoring ECU14verifies validity of the frame to be transmitted from inspection target ECU12based on the Hash chain. This makes it possible to highly accurately discriminate whether the frame which is being sent through CAN16is normal or abnormal without using key information.

The Hash function is a one-way function, and calculation in an opposite direction requires a brute force attack. Even if an invalid person obtains a commitment registered in monitoring ECU14(herein, authenticator (N)), it is very difficult for the invalid person to obtain authenticator (N-D. Therefore, when verification of authenticator (N-D included in the frame to be inspected succeeds, the frame to be inspected is guaranteed to be transmitted from valid inspection target ECU12.

Further, since an attacker does not know an input value (authenticator (N−1)) for the commitment (authenticator (N)), even if an ECU taken over by the attacker spoofs inspection target ECU12, Hash chain authentication results in NG so that spoofing can be detected. Further, even if the attacker falsifies a commitment, monitoring ECU14doubly accepts commitment registration frames with the same IDs to detect falsification.

The present disclosure has been described above according to the exemplary embodiment. It will be understood by those skilled in the art that the exemplary embodiment is merely example, other modifications in which components or processes of the exemplary embodiment are variously combined are possible, and the other modifications will still fall within the scope of the present disclosure.

In a first modification, Hash chain authentication and MAC authentication are used in combination. In the normal MAC authentication, a synthetic value of a predetermined initial value (IV), a common key for a MAC, and data (a message text) is input into a Hash function for the MAC, and a Hash value output from the Hash function is used as the MAC. In the first modification, the authenticators described in the exemplary embodiment are used as the IV. That is, in the first modification, a Hash value based on a synthetic value of an authenticator, a predetermined common key, and data (a message text) is used as the MAC. The predetermined common key may be a key for each vehicle or a key shared among a plurality of ECUs in vehicle10.

FIG. 11illustrates an example of the normal frame output from inspection target ECU12according to the first modification. The normal frame according to the first modification further includes a MAC. Frame generation unit28of inspection target ECU12obtains, as the MAC, the Hash value based on the synthetic value of the authenticator, the common key for the MAC, and the data (the message text) during generation of the normal frame, and sets the obtained MAC in the normal frame. The MAC may be added to the commitment registration frame.

When receiving the normal frame transmitted from inspection target ECU12as the frame to be inspected, determination unit38of monitoring ECU14verifies an authenticator included in the frame to be inspected (in other words, the IV of the MAC) similarly to the exemplary embodiment. At the same time, determination unit38verifies the MAC included in the frame to be inspected according to a commonly-known method. For example, determination unit38may generate a collation value based on the authenticator, the data (the message text), and the predetermined common key included in the frame to be inspected. When the generated collation value matches the MAC included in the frame to be inspected, determination unit38may determine that the verification of the MAC succeeds.

When at least one of the verification using an authenticator and verification using a MAC fails, determination unit38specifies an invalid state in accordance with combinations of success/failure of the verification using the authenticator and success/failure of the verification using the MAC. Herein, three cases will be described as follows.

Case1: As to a frame to be inspected transmitted from a first ECU (namely, an ID related to the first ECU is set), verification using the authenticator fails and verification using the MAC succeeds.

Case2: As to the frame to be inspected, the verification using the authenticator fails and the verification using the MAC also fails.

Case3: As to the frame to be inspected, the verification using the authenticator succeeds and the verification using the MAC fails.

In case1, a second ECU taken over by an invalid person transmits a frame having the ID associated with the first ECU. In this case, determination unit38determines that the second ECU spoofs the first ECU and inserts a frame. In case2, determination unit38determines that invalid frame (a command) is inserted from an outside of vehicle10. Further, in case3, determination unit38determines that a third party ECU is physically added. Abnormality processor42outputs a log representing a determined result obtained by determination unit38to a predetermined storage area.

FIG. 12AtoFIG. 12Cillustrate output examples of the log from monitoring ECU14according to the first modification.FIG. 12Aillustrates the log indicating a normal state at an activating time.FIG. 12Billustrates the log indicating an abnormal state at the activating time.FIG. 12AandFIG. 12Billustrate the logs output by monitoring ECU14when each inspection target ECU12registers a commitment in monitoring ECU14upon starting of the engine. Specifically,FIG. 12A and 12Billustrate that since a MAC is not added to a frame from ECU4although MACs are supposed to be added to all frames, a determination is made that the state is abnormal.

FIG. 12Cillustrates the log indicating an abnormal state at a traveling time. Log50indicates that loss of a frame described in the exemplary embodiment is detected. Log52indicates that since the verification using the authenticator fails and the verification using the MAC succeeds, it is detected that a certain ECU spoofs another ECU. Log54indicates that since the verification using the authenticator fails and the verification using the MAC also fails, it is detected that an invalid frame is externally inserted.

According to the modification1, details of an abnormal state can be understood by using both the Hash chain authentication and the MAC authentication. Further, even when a MAC key is a key for each vehicle, a transmission source can be identified by the Hash chain authentication. Further, in order to identify a transmission source, a key does not have to be prepared for each pair of ECUs. As illustrated inFIG. 12AandFIG. 12B, in the first modification, a valid ECU transmits a frame having a MAC. On the other hand, in the above exemplary embodiment, even when a MAC is not added to a frame, monitoring ECU14can detect, as abnormality, that a predetermined number or more of ECUs (inspection target ECUs12) register a commitment.

In a second modification, encryption is used instead of Hash. A data encryption system is not limited, but an example where Advanced Encryption Standard (AES) is used will be illustrated.FIG. 13illustrates a procedure for generating an authenticator according to the second modification. In the generation of an authenticator in the exemplary embodiment (FIG. 3), synthesized data of a time value, an ID, and a random number (or an authenticator) is input into the Hash function. However, in the second modification, the synthesized data is AES-encrypted by using a common fixed key in inspection target ECU12and monitoring ECU14.

A cipher text is truncated so that an authenticator is extracted. For this reason, substantially one-way function is used. For example, it is difficult to estimate authenticator1from authenticator2inFIG. 13. When a bit number of an authenticator is too small, a brute-force attack in an opposite direction becomes easy. For this reason, a size of the authenticator is preferably half or more of a size of the cipher text before truncation. The time value and the ID inFIG. 13may be padding data shared between inspection target ECU12and monitoring ECU14(for example, data of all zero).

Determination unit38of monitoring ECU14performs AES encryption on data obtained by synthesizing a predetermined time value and ID with an authenticator included in a frame to be inspected, based on the common key with respect to inspection target ECU12so as to obtain a cipher text. Determination unit38extracts a verification value from the cipher text in accordance with a common truncation rule with respect to inspection target ECU12. Thereafter, similarly to the exemplary embodiment, determination unit38verifies normality of the frame to be inspected in accordance with whether a verification value matches a commitment value.

Although not described in the exemplary embodiment, one inspection target ECU12may transmit plural types of normal frames having different IDs. In this case, inspection target ECU12may use ECU-ID unique in the self device instead of a frame ID when an authenticator is generated. That is, inspection target ECU12may set, in the plural types of normal frames, an authenticator based on the same Hash chain. For example, inspection target ECU12may set authenticator (998) in a normal frame having a first frame ID, and may set authenticator (997) which is a base of authenticator (998) in a normal frame having a second frame ID.

In the third modification, an ECU-ID is set in a commitment registration frame instead of a frame ID of a normal frame. Further, a record in the commitment management table of monitoring ECU14is generated for each ECU-ID. Further, monitoring ECU14further stores an ID management table in which correspondences between one ECU-ID and one or more frame IDs are defined. The ID management table may be included in the commitment management table.FIG. 14illustrates the commitment management table according to the third modification. In the table in this diagram, one ECU-ID is associated with a plurality of frame IDs, and a commitment value is managed for each ECU.

A method for creating an ID management table will be described. In method1, the ID management table may be stored in a storage of monitoring ECU14at a time of manufacturing monitoring ECU14, or may be provided to monitoring ECU14from a server on a cloud. In method2, inspection target ECU12may include a correspondence between an ECU-ID and a frame ID in a commitment registration frame. Further, inspection target ECU12may transmit a frame dedicated to the correspondence between the ECU-ID and the frame ID to monitoring ECU14at a time of registering a commitment.

In method3, monitoring ECU14may have a learning mode as one of operation modes. Inspection target ECU12may set an authenticator in plural types of normal frames having different frame IDs based on the same Hash chain and may transmit the plural types of normal frames to monitoring ECU14. Monitoring ECU14performs the Hash operation on an authenticator included in plural types of normal frames received in the learning mode to specify plural types of normal frames in which the authenticator based on the same Hash chain is set. Monitoring ECU14may associate a plurality of set frame IDs with the plural types of specified normal frames to record the frame IDs in the ID management table. As a result, the ID management table can be automatically created.

FIG. 15is a flowchart illustrating the process for automatically creating a commitment management table. Monitoring ECU14starts the learning mode when a predetermined condition is satisfied, for example, when the engine is started or the power supply is turned on (S130). Inspection target ECU12transmits a commitment registration frame in which the ECU-ID of the self device is associated with a commitment (commitment x) to CAN16. Monitoring ECU14receives the commitment registration frame, and records the ECU-ID and the commitment x set in the commitment registration frame into the commitment management table (S132).

Thereafter, inspection target ECU12transmits a normal frame including a CAN-ID (herein, “a”) and an authenticator (herein, an authenticator a which is a source of commitment x) to CAN16. Monitoring ECU14receives the normal frame, and obtains CAN-ID_a and authenticator a set in the normal frame (S134). Monitoring ECU14performs the Hash operation on the authenticator a to obtain a verification value (S136). Monitoring ECU14updates the commitment management table so that a commitment that matches the verification value (herein, commitment x) is associated with CAN ID_a (S138). Further, monitoring ECU14updates commitment x to a value of authenticator a.

Thereafter, inspection target ECU12transmits a normal frame including a CAN-ID (herein, “b”) and an authenticator (herein, authenticator b which is a source of authenticator a) to CAN16. Monitoring ECU14receives the normal frame, and obtains CAN-ID_b and authenticator b set in the normal frame (S140). Monitoring ECU14performs the Hash operation on authenticator b to obtain a verification value (S142). Monitoring ECU14updates the commitment management table so that the commitment which matches the verification value (herein, commitment x) is associated with CAN ID_b (S144). Further, monitoring ECU14updates commitment x to a value of authenticator b.

As a result, in the commitment management table, one ECU-ID is associated with CAN-ID_a and CAN-ID_b. Monitoring ECU14repeats S132every time when receiving the commitment registration frame in the learning mode, and repeats S134to S138(or S140to S144) every time when receiving the normal frame. The learning mode may be ended when a predetermined time elapses after the learning mode starts or when an explicit ending instruction is input.

FIG. 16is a diagram describing duplication of a Hash chain. Hash chain60is a Hash chain corresponding toFIG. 4, and a Hash chain including an authenticator which is being currently used. Hash chain62is a Hash chain including an authenticator to be used after the authenticator of Hash chain60. When frame generation unit28of inspection target ECU12uses a certain authenticator of Hash chain60in a normal frame, authenticator generation unit24stores new authenticator of Hash chain62in an area where the used authenticators are stored (a partial area of commitment storage unit26).

Specifically, when authenticator (999) of Hash chain60is used, authenticator generation unit24stores new authenticator (0)∝ of Hash chain62in the storage area. Thereafter, when authenticator (998) of Hash chain60is used, frame generation unit28stores new authenticator (1)∝ of Hash chain62in the storage area. That is, authenticator generation unit24gradually generates an authenticator of Hash chain62every time when the authenticator of Hash chain60is used, and records the generated authenticator in commitment storage unit26. In the present modification, even when inspection target ECU12duplicates the Hash chain, it is only necessary that the storage area for authenticator (0) to authenticator (999) be secured, and therefore a necessary storage capacity can be reduced.

Inspection target ECU12according to the exemplary embodiment entirely stores the plurality of authenticators in the Hash chain into commitment storage unit26. As a modification, authenticator generation unit24of inspection target ECU12may generate an authenticator every time when inspection target ECU12transmits a frame to monitoring ECU14. For example, authenticator generation unit24may generate authenticator (999) at timing when a commitment registration frame should be transmitted. Further, authenticator generation unit24may generate new authenticator (998) at timing when a normal frame should be transmitted next time.

In another modification, commitment storage unit26may store some of the plurality of authenticators in the Hash chain in accordance with a predetermined rule. For example, commitment storage unit26may store authenticator (0), authenticator (99), authenticator (199), . . . , authenticator (899), and authenticator (999), namely, every100th authenticator after first authenticator (0). Authenticator generation unit24may obtain a stored authenticator which is the closest to an authenticator to be used from stored authenticators which are earlier than the authenticator to be used, and may start the Hash operation on the stored authenticator to generate the authenticator to be used. Any one of the method in the exemplary embodiment and the method described in the fifth modification may be selected in view of a calculation cost and a storage capacity of the storage.

A plurality of nodes (ECUs or the like) in in-vehicle network system18may have a function of monitoring ECU14according to the exemplary embodiment and may simultaneously check normality of a frame received from the bus of CAN16.

Monitoring ECU14may be mounted to a dedicated ECU, and may be mounted as a software module.

A bit length of the commitment management table may be estimated based on a transmission cycle of inspection target ECU12. An example will be described below. 2̂(N−1) operations are necessary in average for cracking N-bit

Hash through brute-force. In accordance with the following estimation, the bit length is determined in view of assumed computing power of an attack ECU.

When both the Hash chain authentication and the MAC authentication are used, a MAC value is shortened and an authenticator can be made long. Therefore, a length of a MAC value may be determined in accordance with an importance level (criticality) of a frame (a message). The authentication of an N-bit MAC value succeeds only with ½̂N as long as a key is not known. Further, the Hash chain authentication makes the detection of an abnormal state easy. Further, even if the MAC value is shortened, a risk of a leakage of the key does not become high.

Determination unit38of monitoring ECU14stores an error probability due to a frame collision as a threshold in advance. When the probability that a Hash chain authentication is an error exceeds the threshold, a determination may be made as abnormal.

Inspection target ECU12may add at least one of a MAC and a signature to a commitment registration frame. As a result, spoofing can be prevented.

At times of manufacturing inspection target ECU12and monitoring ECU14, the same random number sequence may be saved in them respectively. At a time of first commitment registration from inspection target ECU12to monitoring ECU14, the random number sequence may be set as a value of an old authenticator. As a result, use of a default value “0000...” can be suppressed.

In an environment where a random value generating ability is low, a pseudo random number may be generated by using encryption or Hash. When addition of a new record into the commitment management table is requested, commitment registration unit32of monitoring ECU14may verify a signature added to the request and may update the commitment management table under condition that the verification succeeds.

In the commitment management table of monitoring ECU14, both a commitment value based on a current Hash chain (“a new commitment value”) and a commitment value based on a previous Hash chain (“an old commitment value”) may be stored. Determination unit38of monitoring ECU14may verify an authenticator using both the old and new commitment values until synchronization of commitment updating can be checked.

For example, when receiving a commitment registration frame that requests re-registration of a commitment for a certain frame ID (or an ECU-ID), commitment registration unit32of monitoring ECU14changes an earlier new commitment value into an old commitment value, and may save a commitment value indicated by the commitment registration frame as a new commitment value. Commitment registration unit32may transmit acknowledgment (ACK) data representing completion of the commitment value updating to inspection target ECU12.

Before reception of the ACK data, inspection target ECU12may set, in a normal frame, an authenticator based on a previous Hash chain. After the reception of the ACK data, inspection target ECU12may set, in the normal frame, an authenticator based on a current Hush chain. Determination unit38of monitoring ECU14may use both the new commitment value and the old commitment value after the reception of the ACK data to verify an authenticator of the normal frame. In subsequent verification, determination unit38may use only the new commitment value when the verification of the authenticator based on the new commitment value succeeds.

The techniques described in the exemplary embodiment and the modifications can also be applied to communication methods other than the CAN. For example, the techniques can also be applied to an Ethernet (registered trade name), Media Oriented Systems Transport (MOST) (registered trade name), and FlexRay (registered trade name).

The techniques described in the exemplary embodiment and the modifications may also be identified through items described below.

A communication system includes a first electronic device connected to a bus network, and a second electronic device that is connected to the bus network and monitors a state of the first electronic device. The first electronic device includes a transmitter that transmits a first frame including a first verification value forming a Hash chain to the bus network. The second electronic device includes a storage unit that stores the first verification value included in the first frame received from the bus network. The transmitter of the first electronic device transmits, after transmission of the first frame, a second frame including a second verification value forming the Hash chain to the bus network. The second electronic device further includes a determination unit that determines that the state of the first electronic device is normal when the second verification value included in the second frame received from the bus network and the first verification value stored in the storage unit construct the Hash chain.

According to the communication system, the second electronic device authenticates validity of a frame transmitted by the first electronic device, based on the Hash chain. This makes it possible to highly accurately discriminate whether a frame which is being sent in the bus network is normal or abnormal without using key information.

The transmitter of the first electronic device may transmit the first frame which includes an Nth in the Hash chain as the first verification value, and may transmit the second frame which includes an N−1st value in the Hash chain as the second verification value. N is an integer of 2 or more. The determination unit of the second electronic device may determine that the state of the first electronic device is normal when a result of a Hash operation based on the second verification value included in the second frame matches the first verification value.

According to this aspect, an electronic device that can transmit an appropriate second verification value is only the first electronic device that has constructed the Hash chain, and thus even if an invalid electronic device spoofs the first electronic device, spoofing can be detected. That is, validity of a transmission source of the second frame can be authenticated.

The storage unit of the second electronic device may further store a number of operation times according to a number of frames to be discarded by a third electronic device among frames transmitted by the first electronic device. The determination unit of the second electronic device may determine that the state of the first electronic device is normal when a result of performing a Hash operation based on the second verification value included in the second frame at the number of operation times matches the first verification value. According to this aspect, even when the third electronic device, such as a gateway, which relays a frame between different bus networks, deletes a part of a frame transmitted by the first electronic device, validity of the first electronic device can be accurately determined.

The transmitter of the first electronic device may transmit the second frame further including a message authentication code. The determination unit of the second electronic device may determine the state of the first electronic device based on both a determination result using the second verification value included in the second frame and a determination result using the message authentication code included in the second frame.

According to this aspect, an increase in a key management cost can be suppressed and simultaneously a security level can be further enhanced by using both authentication based on the Hash chain and authentication based on a message authentication code.

A vehicle includes a first electronic device connected to an in-vehicle bus network, and a second electronic device that is connected to the in-vehicle bus network and monitors a state of the first electronic device. The first electronic device includes a transmitter that transmits a first frame including a first verification value forming a Hash chain to the in-vehicle bus network. The second electronic device includes a storage unit that stores the first verification value included in the first frame received from the in-vehicle bus network. The transmitter of the first electronic device transmits, after transmission of the first frame, a second frame including a second verification value forming the Hash chain to the in-vehicle bus network. The second electronic device further includes a determination unit that determines that the state of the first electronic device is normal when the second verification value included in the second frame received from the in-vehicle bus network and the first verification value stored in the storage unit construct the Hash chain.

According to the vehicle, the second electronic device authenticates validity of a frame transmitted by the first electronic device based on the Hash chain. This makes it possible to highly accurately discriminate whether a frame which is being sent in the bus network is normal or abnormal without using key information.

A monitoring method includes a first electronic device transmitting a first frame including a first verification value forming a Hash chain to an in-vehicle bus network. The first electronic device is connected to the in-vehicle bus network. Further, the monitoring method includes a second electronic device storing the first verification value included in the first frame received from the in-vehicle bus network into a storage unit. The second electronic device is connected to the in-vehicle bus network and monitors a state of the first electronic device. The monitoring method further includes the first electronic device transmitting, after the transmitting of the first frame, a second frame including a second verification value forming the Hash chain to the in-vehicle bus network. Further, the monitoring method includes the second electronic device determining that the state of the first electronic device is normal when the second verification value included in the second frame received from the in-vehicle bus network and the first verification value stored in the storage unit construct the Hash chain.

According to this monitoring method, the second electronic device authenticates validity of a frame transmitted by the first electronic device based on the Hash chain. This makes it possible to highly accurately discriminate whether a frame which is being sent in the bus network is normal or abnormal without using key information.

Any desired combinations of the above described exemplary embodiment and the above described modifications are also useful as other exemplary embodiments of the present disclosure. Any new exemplary embodiments formed by such combinations include benefits of the exemplary embodiment and the modifications combined into the new exemplary embodiments. It will be understood by those skilled in the art that functions that should be carried out by components described in the appended claims can be achieved by each of or through cooperation of the components illustrated in the exemplary embodiment and the modifications.

The present disclosure relates to a data processing technique, and particularly is useful as a communication system, a vehicle, and a monitoring method.