Systems, vehicles and methods

Abstract

To provide a system for surely authenticating a message, a vehicle and a method.SOLUTION: A system is provided with an authentication part for authenticating a message at least including control data transmitted and received between a plurality of on-vehicle devices and a first counter that is counted each time a power source is turned on by using at least the control data and the first counter in the case of authenticating the message including the control data exchanged between the plurality of on-vehicle devices. The authentication part authenticates a message including a second counter to be incremented over time without including the first counter transmitted and received between the on-vehicle devices, without using the second counter instead of the first counter in the case of confirming whether synchronization is performed between the plurality of on-vehicle devices.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present invention relates to a system, a vehicle and a method. [Background technology]

[0002] Patent Document 1 discloses that in an electronic control device provided in an automobile, the key is switched every time the ignition is turned on eight times. [Prior art document] [Patent documents] [Patent Document 1] International Publication No. 2019 / 159593 Summary of the Invention [Problem to be solved by the invention]

[0003] However, ensuring that message authentication is performed reliably is an issue. The present application aims to improve safety in order to solve the above issue. This will ultimately contribute to further improving traffic safety and the development of sustainable transportation systems. [Means for solving the problem]

[0004] In a first aspect of the present invention, there is provided a system. The system includes a plurality of in-vehicle devices and has a function of determining an abnormality in communication among the plurality of in-vehicle devices by authenticating a message including data, a first counter that is counted each time the device is powered on, and a second counter that is incremented over time. The system includes an authentication unit that, when authenticating a message including control data exchanged among the plurality of in-vehicle devices, performs authentication on a message that includes at least the control data and the first counter and is exchanged among the plurality of in-vehicle devices, using at least the control data and the first counter. When confirming whether synchronization is achieved among the plurality of in-vehicle devices, the authentication unit performs authentication on a message that does not include the first counter but includes the second counter and is exchanged among the plurality of in-vehicle devices, using the second counter instead of the first counter.

[0005] When checking whether synchronization is achieved between the multiple on-board devices, the authentication unit may determine that synchronization is not achieved between the multiple on-board devices if a period during which negative authentication results are obtained as authentication results for multiple messages received in succession exceeds a predetermined time.

[0006] The system may further include a control unit that controls the vehicle without using the types of data exchanged between the multiple on-board devices if synchronization between the multiple on-board devices cannot be confirmed.

[0007] The plurality of in-vehicle devices may include a first in-vehicle device that transmits a message including a yaw rate of the vehicle as data, and a second in-vehicle device that receives the message including the yaw rate as data. When the second in-vehicle device cannot confirm that synchronization is achieved among the plurality of in-vehicle devices, the second in-vehicle device may prohibit control using the yaw rate and continue control without using the yaw rate.

[0008] When control data is transmitted and received between the plurality of in-vehicle devices, the authentication unit may perform authentication using the control data, the first counter, and the second counter for a message including the control data, the first counter, and the second counter transmitted and received between the plurality of in-vehicle devices.

[0009] When checking whether synchronization is achieved between the multiple on-board devices, the authentication unit may determine that synchronization is not achieved between the multiple on-board devices if the number of times that negative authentication results are obtained as authentication results for multiple messages received in succession exceeds a predetermined number.

[0010] After confirming that synchronization is achieved between the plurality of on-board devices, the authentication unit may perform authentication using the control data, the first counter, and the second counter for a message including the control data, the first counter, and the second counter that is transmitted and received between the plurality of on-board devices.

[0011] In a second aspect of the present invention, there is provided a vehicle, the vehicle comprising the system described above.

[0012] In a third aspect of the present invention, there is provided a method, the method comprising: when authenticating a message including control data exchanged between a plurality of in-vehicle devices, performing authentication on a message including at least the control data exchanged between the plurality of in-vehicle devices and a first counter that is counted each time the plurality of in-vehicle devices are powered on, by using at least the control data and the first counter; when confirming whether the plurality of in-vehicle devices are synchronized, performing authentication on a message exchanged between the plurality of in-vehicle devices that does not include the first counter but includes a second counter that is incremented over time, by using the second counter without using the first counter; and determining that the plurality of in-vehicle devices are not synchronized when a period during which negative authentication results are obtained as authentication results for a plurality of consecutively received messages exceeds a predetermined time.

[0013] The above summary of the invention does not list all of the features of the present invention, and subcombinations of these features may also constitute inventions. [Brief explanation of the drawings]

[0014] [Figure 1] 1 conceptually illustrates a system configuration of a vehicle 10 in one embodiment. [Figure 2] 2 is a block diagram schematically showing a functional configuration of an ECU 110. FIG. [Figure 3] FIG. 10 is a diagram for explaining message authentication processing in an ECU. [Figure 4] 10 shows an example of a sequence for transmitting and receiving messages between ECU 110 and ECU 111 using a trip count. [Figure 5] 10 shows an example of a sequence for transmitting and receiving messages between ECU 110 and ECU 111 using a trip count. [Figure 6] 10A and 10B show a schematic diagram of a process performed to check whether or not the ECUs 110, 111, and 112 are synchronized with each other. [Figure 7] An example of a computer 2000 is shown schematically. DETAILED DESCRIPTION OF THE INVENTION

[0015] The present invention will be described below through embodiments of the invention, but the following embodiments do not limit the scope of the invention according to the claims. Furthermore, not all of the combinations of features described in the embodiments are necessarily essential to the solution of the invention.

[0016] 1 conceptually illustrates a system configuration of a vehicle 10 according to an embodiment. The vehicle 10 includes a system 20. The system 20 includes a plurality of ECUs (electronic control units) including an ECU 100, an ECU 110, an ECU 111, an ECU 112, an ECU 120, an ECU 121, and an ECU 122. The ECUs included in the vehicle 10 include ECUs for controlling devices that directly affect the running of the vehicle 10, such as an engine, a transmission, a steering device, etc. The ECUs included in the vehicle 10 include ECUs for controlling devices that do not directly affect the running of the vehicle 10, such as an air conditioner and a navigation device, etc.

[0017] The ECUs included in the vehicle 10 communicate with each other via controller area network (CAN) communication. The ECUs included in the vehicle 10 are communicably connected to each other via a plurality of CAN communication networks 180. The ECU 100 may function as a gateway that relays communication between the plurality of CAN communication networks 180.

[0018] 2 is a block diagram showing a schematic functional configuration of the ECU 110, the ECU 111, and the ECU 112. The ECU 110, the ECU 111, and the ECU 112 each include a processing unit 200 and a storage unit 280.

[0019] The ECU 110, the ECU 111, and the ECU 112 are examples of in-vehicle devices. As an example, the ECU 110 may be an ECU for controlling a vehicle stability assist (VSA) (registered trademark). The ECU 111 and the ECU 112 may be an ECU for controlling an electric power steering (EPS), an SRS (Supplemental Restraint System), or an ECU for controlling an electronic brake system (EBS).

[0020] The processing unit 200 may be implemented by a processor such as a CPU that performs arithmetic processing. The storage unit 280 may include a non-volatile storage medium such as a flash memory, or a volatile storage medium such as a random access memory. The ECU 110, ECU 111, and ECU 112 may each include a computer. The ECU 110, ECU 111, and ECU 112 perform various types of control by the processing unit 200 operating in accordance with programs stored in the non-volatile storage medium.

[0021] The processing unit 200 includes a receiving unit 210, an authentication unit 220, and a control unit 240. In the description of Fig. 2, the authentication units 220 included in the ECU 110, the ECU 111, and the ECU 112 may be collectively referred to as "authentication units 220." The receiving unit 210 receives data transmitted and received between other ECUs.

[0022] The ECU 110, ECU 111, and ECU 112 have a function of determining an abnormality in communication among the ECU 110, ECU 111, and ECU 112 by authenticating a message including transmitted and received data, a first counter that is counted each time the power is turned on, and a second counter that is incremented over time. The message is authenticated using a message authentication code (MAC). As will be described later, the first counter is, for example, a trip counter, and the second counter is, for example, a reset counter.

[0023] The authentication unit 220 is responsible for processing related to message authentication. For example, the authentication unit 220 is responsible for processing to generate a MAC to be added to a message to be transmitted. The authentication unit 220 is also responsible for processing to authenticate a received message by verifying the MAC added to the message.

[0024] When authenticating a message including control data exchanged between the ECU 110, the ECU 111, and the ECU 112, the authentication unit 220 performs authentication using at least the control data and the first counter for a message that includes at least the control data and a first counter exchanged between the ECU 110, the ECU 111, and the ECU 112. When checking whether synchronization is achieved between the ECU 110, the ECU 111, and the ECU 112, the authentication unit 220 performs authentication using the second counter without using the first counter for a message that does not include the first counter but includes a second counter exchanged between the ECU 110, the ECU 111, and the ECU 112. By not using the first counter when checking whether synchronization is achieved, it is possible to determine through message authentication whether synchronization is achieved, for example, after the ignition (IG) power of the vehicle 10 is turned on.

[0025] When checking whether synchronization is achieved among the ECUs 110, 111, and 112, the authentication unit 220 determines that synchronization is not achieved among the ECUs 110, 111, and 112 if the period during which negative authentication results are obtained as authentication results for multiple consecutively received messages exceeds a predetermined time. The predetermined time may be, for example, three seconds. This makes it possible to reliably determine whether synchronization is achieved. In this embodiment, multiple consecutively received messages refer to multiple consecutively received messages that specify the same CAN ID.

[0026] If the control unit 240 cannot confirm that synchronization is achieved among the ECU 110, ECU 111, and ECU 112, it controls the vehicle 10 without using the types of data exchanged among the ECU 110, ECU 111, and ECU 112. As an example, if the ECU 110 is an ECU for VSA control and the ECU 111 is an ECU for EPS control, and it is determined that synchronization is not achieved, the control unit 240 of the ECU 111 performs steering control in a control mode that does not use the wheel speed transmitted from the ECU 110. The control unit 240 of the ECU 111 may perform control that does not use power steering. This makes it possible to prevent the vehicle 10 from being prohibited from traveling.

[0027] At least one of the ECUs 110, 111, and 112 includes a first ECU that transmits a message including the yaw rate of the vehicle 10 as data, and a second ECU that receives the message including the yaw rate as data. If the second ECU cannot confirm that synchronization is achieved among the ECUs 110, 111, and 112, it prohibits control that uses the yaw rate and continues control that does not use the yaw rate. For example, if the ECU 112 is an ECU for SRS control and the ECU 111 is an ECU for EPS control, the control unit 240 of the ECU 111 performs ESB control in a control mode that does not use the yaw rate transmitted from the ECU 112. This prevents the vehicle 10 from being prohibited from traveling.

[0028] When control data is transmitted and received between the ECU 110, the ECU 111, and the ECU 112, the authentication unit 220 uses the control data, the first counter, and the second counter to perform authentication on a message including the control data, the first counter, and the second counter transmitted and received between the ECU 110, the ECU 111, and the ECU 112. When control data is transmitted and received, the authentication unit 220 uses the first counter to authenticate the data, thereby increasing resistance to attacks by malicious third parties.

[0029] When checking whether synchronization is achieved among the ECU 110, ECU 111, and ECU 112, if the number of times that negative authentication results are obtained as authentication results for multiple consecutively received messages exceeds a predetermined number, the authentication unit 220 determines that synchronization is not achieved among the ECU 110, ECU 111, and ECU 112. This makes it possible to determine whether or not a dealer's action is required.

[0030] After it is confirmed that synchronization is achieved among the ECU 110, the ECU 111, and the ECU 112, the authentication unit 220 uses the control data, the first counter, and the second counter to perform authentication on messages including the control data, the first counter, and the second counter transmitted and received among the ECU 110, the ECU 111, and the ECU 112. In this way, after it is confirmed that synchronization is achieved among the ECU 110, the ECU 111, and the ECU 112, the authentication unit 220 uses the first counter to authenticate the data, thereby increasing resistance to attacks by malicious third parties.

[0031] 3 is a diagram for explaining message authentication processing in an ECU, showing the authentication processing when control data generated by the transmitting ECU is transmitted and received between a transmitting ECU and a receiving ECU.

[0032] In the transmitting ECU, the authentication unit 220 generates control data to be transmitted to the receiving ECU. The control data is, for example, sensor data detected by a sensor. For example, the control data may be sensor data such as yaw rate and vehicle speed.

[0033] The authentication unit 220 of the transmitting ECU generates a MAC using the control data, a freshness value (FV), and a key. The FV is a value that can be updated in the transmitting ECU to prevent replay attacks. For example, the FV may be generated based on a trip counter that is incremented each time the ignition (IG) power of the vehicle 10 is turned on and a reset counter that is incremented every predetermined time. The reset counter may be incremented every second, for example. The key is a shared key shared between the transmitting ECU and the receiving ECU.

[0034] The authentication unit 220 of the transmitting ECU sends a CAN data frame including the control data, FV, and MAC to the CAN communication network 180. For example, the authentication unit 220 stores the control data, FV, and MAC in a data field with a data length of 64 bits and sends it to the CAN communication network 180.

[0035] When the receiving ECU receives the CAN data frame data transmitted to the CAN communication network 180, the authentication unit 220 of the receiving ECU generates a MAC using the control data, FV, and key included in the received data frame. The key is a shared key shared between the transmitting ECU and the receiving ECU. The authentication unit 220 may generate a MAC using the FV included in the data frame. The authentication unit 220 of the receiving ECU may generate a MAC using the FV updated in the ECU 110.

[0036] The authentication unit 220 of the receiving ECU determines whether the authentication result is positive or negative based on a comparison between the generated MAC and the MAC included in the received data frame. For example, if the generated MAC matches the MAC included in the received data frame, the authentication unit 220 of the receiving ECU determines that the authentication result is positive (OK). If the generated MAC does not match the MAC included in the received data frame, the authentication unit 220 of the receiving ECU determines that the authentication result is negative (NG).

[0037] If the authentication result is negative, the authentication unit 220 of the receiving ECU can determine that an abnormality has occurred in the CAN communication network 180. An example of a case in which the authentication result can be negative is when the key held by the transmitting ECU does not match the key held by the receiving ECU. An example of a case in which the key held by the transmitting ECU does not match the key held by the receiving ECU is when the control software of the transmitting ECU and the receiving ECU is updated over the air (OTA) and the control software of one of the transmitting ECU and the receiving ECU is not updated normally.

[0038] Another example of a case in which the authentication result may be negative is when the FV updated in the transmitting ECU does not match the FV updated in the receiving ECU due to a transmission delay or the like. Another example of a case in which the authentication result may be negative is when control data is not transmitted normally due to noise or the like in the CAN communication network 180. Another example of a case in which the authentication result may be negative is when an unauthorized data frame is input to the CAN communication network 180 by a malicious third party.

[0039] 4 shows an example of a sequence for transmitting and receiving messages between ECU 110 and ECU 111 using trip counts. Here, ECU 110 is assumed to be the transmitting ECU and ECU 111 is assumed to be the receiving ECU. After the IG power supply of vehicle 10 is turned on, it is assumed that communication involving authentication processing using MAC is not being performed between ECU 110 and ECU 111 at the time the transmission and reception sequence of FIG. 4 starts. It is assumed that when the IG power supply of vehicle 10 is turned on, the trip count held by each ECU provided in vehicle 10 becomes 5.

[0040] In S410, the authentication unit 220 of the ECU 110 sends a message including the trip count as the FV and the MAC to the CAN communication network 180. When the ECU 111 receives the message, the authentication unit 220 of the ECU 111 performs the above-described authentication process and obtains a positive authentication result (authentication OK).

[0041] In S420, the ECU 110 sends a message including the trip count and MAC as FV to the CAN communication network 180. The trip count is incremented each time the IG power supply is turned on. After the IG power supply is turned on, the trip count does not change from the time the IG power supply is turned off. When the ECU 111 receives the message, the authentication unit 220 of the ECU 111 determines whether the trip count value matches the value used in previous authentication. In accordance with the specifications defined by JASPAR (Japan Automotive Software Platform and Architecture), if the trip count value matches the value used in previous authentication, the authentication unit 220 of the ECU 111 determines that authentication has been successful without performing authentication using MAC (authentication OK). Similarly, when the ECU 111 receives a message with the same trip count thereafter, the authentication unit 220 determines that authentication has been successful.

[0042] Fig. 5 shows an example of a sequence for transmitting and receiving messages using trip counts between ECU 110 and ECU 111. Fig. 5 shows a sequence in which the key for MAC generation in ECU 111 has been updated by a software update, but the key for MAC generation in ECU 110 has not been updated due to a software update failure.

[0043] As in Fig. 4, ECU 110 is the transmitting ECU and ECU 111 is the receiving ECU. After the IG power supply of vehicle 10 is turned on, communication involving authentication processing using MAC is not performed between ECU 110 and ECU 111 at the time the transmission / reception sequence in Fig. 5 starts. When the IG power supply of vehicle 10 is turned on, the trip count held by each ECU provided in vehicle 10 is assumed to be 5.

[0044] In S510, the authentication unit 220 of the ECU 110 sends a message including the trip count as the FV and the MAC to the CAN communication network 180. When the ECU 111 receives the message, the authentication unit 220 of the ECU 111 performs the above-described authentication process and obtains a positive authentication result (authentication OK).

[0045] In S512, the software of the ECU 111 is updated, and thus the MAC generation key held by the ECU 111 is updated. On the other hand, the software update of the ECU 110 has failed, and therefore the MAC generation key held by the ECU 110 is not updated. As a result, the MAC generation keys of the ECU 110 and the ECU 111 do not match.

[0046] In S520, the ECU 110 transmits a message including the trip count as the FV and the MAC to the CAN communication network 180. In accordance with the specifications defined by JASPAR (Japan Automotive Software Platform and Architecture), if the value of the trip count matches the value used in previous authentication, the authentication unit 220 of the ECU 111 determines that authentication has been successful (authentication OK) without performing authentication using the MAC. As a result, even if the keys for MAC generation between the ECU 110 and the ECU 111 do not match, it is determined that authentication has been successful. Therefore, it is not possible to detect that the keys for MAC generation between the ECU 110 and the ECU 111 do not match.

[0047] FIG. 6 shows a schematic diagram of the process performed to check whether the ECU 110, ECU 111, and ECU 112 are synchronized with each other.

[0048] The ECU 110 functions as an FV master, and the ECUs 111 and 112 function as FV slaves. The ECU 110 transmits a synchronization message to the ECUs 111 and 112, instructing them to check whether synchronization is achieved between the ECUs 111 and 112. Upon receiving the synchronization message, the authentication unit 220 of the ECU 111 sets an FV that includes a reset counter but does not include a trip counter. The authentication unit 220 generates a MAC using the data to be transmitted to the ECU 112, the FV, and a key currently held by the ECU 111, and transmits a message including the data, the FV, and the MAC to the CAN communication network 180.

[0049] When the ECU 112 receives a message transmitted from the ECU 111, the authentication unit 220 of the ECU 112 determines whether the reset counter included in the received message matches the reset counter held by the ECU 112. If they match, the authentication unit 220 performs authentication by comparing the MACs using the authentication process described above. If a positive authentication result is obtained, it can be determined that the keys between the ECU 111 and the ECU 112 match. If a negative authentication result is obtained, it can be determined that the keys between the ECU 111 and the ECU 112 do not match. The authentication unit 220 of the ECU 112 generates a MAC using data indicating whether a positive or negative authentication result was obtained, the reset counter as the FV, and the key currently held by the ECU 112, and transmits a message including the data, the FV, and the MAC to the CAN communication network 180.

[0050] When ECU 110 receives a message transmitted from ECU 112, authentication unit 220 of ECU 110 determines whether the reset counter included in the received message matches the reset counter held by ECU 110. If they match, authentication is performed by comparing the MACs using the authentication process described above. If a positive authentication result is obtained and the data included in the message received from ECU 112 indicates that a positive authentication result has been obtained, authentication unit 220 of ECU 110 determines that synchronization is achieved among ECU 110, ECU 111, and ECU 112. In other words, authentication unit 220 of ECU 110 determines that the reset counters and keys match among ECU 110, ECU 111, and ECU 112.

[0051] On the other hand, if a positive authentication result is obtained, or if the data included in the message received from the ECU 112 indicates that a negative authentication result is obtained, the authentication unit 220 of the ECU 110 determines that synchronization is not achieved among the ECU 110, the ECU 111, and the ECU 112. In other words, the authentication unit 220 of the ECU 110 determines that the reset counters or keys do not match among the ECU 110, the ECU 111, and the ECU 112.

[0052] As described in relation to Fig. 6, when checking whether synchronization is achieved among the ECU 110, the ECU 111, and the ECU 112, the trip counter is not used, thereby making it possible to detect a state in which the keys do not match between the ECU 110 and the ECU 111 and ECU 112. Note that, when data included in a message received from the ECU 112 indicates that a negative authentication result has been obtained, the authentication unit 220 of the ECU 112 can determine that the keys do not match between the ECU 111 and the ECU 112. Therefore, the authentication unit 220 of the ECU 110 can detect whether a state in which the keys do not match between at least one of the ECU 110, the ECU 111, and the ECU 112 has occurred.

[0053] The authentication unit 220 of the ECU 110 may determine that synchronization is not achieved among the ECU 110, ECU 111, and ECU 112 when the number of times that synchronization is not achieved among the ECU 110, ECU 111, and ECU 112 for multiple consecutively transmitted synchronization messages exceeds a predetermined number of times. The authentication unit 220 of the ECU 110 may determine that synchronization is not achieved among the ECU 110, ECU 111, and ECU 112 when the period during which synchronization is not achieved among the ECU 110, ECU 111, and ECU 112 for multiple consecutively transmitted synchronization messages exceeds a predetermined time. This reduces the possibility of false detection of a synchronized state.

[0054] 7 shows an example of a computer 2000 in which multiple embodiments of the present invention may be embodied in whole or in part. A program installed on the computer 2000 may cause the computer 2000 to function as a system or each part of a system, such as system 20 according to an embodiment, or as an apparatus or each part of an apparatus, such as ECU 110, ECU 111, and ECU 112, perform operations associated with the system or each part of the system or the apparatus or each part of the apparatus, and / or perform a process or steps of the process according to an embodiment. Such a program may be executed by the CPU 2012 to cause the computer 2000 to perform specific operations associated with some or all of the processing procedures and blocks of the block diagrams described herein.

[0055] The computer 2000 according to this embodiment includes a CPU 2012 and a RAM 2014, which are interconnected by a host controller 2010. The computer 2000 also includes a ROM 2026, a flash memory 2024, a communication interface 2022, and an input / output chip 2040. The ROM 2026, the flash memory 2024, the communication interface 2022, and the input / output chip 2040 are connected to the host controller 2010 via the input / output controller 2020.

[0056] The CPU 2012 operates according to programs stored in the ROM 2026 and RAM 2014, thereby controlling each unit.

[0057] The communication interface 2022 communicates with other electronic devices via a network. The flash memory 2024 stores programs and data used by the CPU 2012 in the computer 2000. The ROM 2026 stores a boot program and the like executed by the computer 2000 upon activation, and / or programs dependent on the hardware of the computer 2000. The input / output chip 2040 may also connect various input / output units such as a keyboard, mouse, and monitor to the input / output controller 2020 via input / output ports such as a serial port, a parallel port, a keyboard port, a mouse port, a monitor port, a USB port, an HDMI (registered trademark) port, etc.

[0058] The programs are provided via a computer-readable storage medium such as a CD-ROM, a DVD-ROM, or a memory card, or via a network. The RAM 2014, the ROM 2026, or the flash memory 2024 are examples of computer-readable storage media. The programs are installed in the flash memory 2024, the RAM 2014, or the ROM 2026 and executed by the CPU 2012. Information processing described in these programs is read by the computer 2000, and causes cooperation between the programs and the various types of hardware resources described above. An apparatus or a method may be configured by implementing operations or processing of information in accordance with the use of the computer 2000.

[0059] For example, when communication is performed between the computer 2000 and an external device, the CPU 2012 may execute a communication program loaded into the RAM 2014 and instruct the communication interface 2022 to perform communication processing based on the processing described in the communication program. Under the control of the CPU 2012, the communication interface 2022 reads transmission data stored in a transmission buffer processing area provided in a recording medium such as the RAM 2014 or flash memory 2024, transmits the read transmission data to a network, and writes received data received from the network to a reception buffer processing area or the like provided on the recording medium.

[0060] The CPU 2012 may also cause all or a necessary portion of a file or database stored on a recording medium such as the flash memory 2024 to be read into the RAM 2014, and perform various types of processing on the data on the RAM 2014. The CPU 2012 then writes the processed data back to the recording medium.

[0061] Various types of information, such as various types of programs, data, tables, and databases, may be stored on the recording medium and subjected to information processing. The CPU 2012 may perform various types of processing on data read from the RAM 2014, including various types of operations, information processing, conditional judgment, conditional branching, unconditional branching, information search / replacement, etc., as described herein and specified by the instruction sequences of the programs, and write the results back to the RAM 2014. The CPU 2012 may also search for information in a file, database, etc. on the recording medium. For example, if multiple entries each having an attribute value of a first attribute associated with an attribute value of a second attribute are stored on the recording medium, the CPU 2012 may search for an entry that matches a condition specified by the attribute value of the first attribute from among the multiple entries, read the attribute value of the second attribute stored in the entry, and thereby obtain the attribute value of the second attribute associated with the first attribute that satisfies a predetermined condition.

[0062] The above-described programs or software modules may be stored in a computer-readable storage medium on or near the computer 2000. A recording medium such as a hard disk or RAM provided in a server system connected to a dedicated communication network or the Internet can be used as the computer-readable storage medium. The programs stored in the computer-readable storage medium may be provided to the computer 2000 via a network.

[0063] A program installed in computer 2000 and causing computer 2000 to function as ECU 110 may act on CPU 2012 or the like to cause computer 2000 to function as each unit of ECU 110. When the information processing described in these programs is read into computer 2000, it functions as each unit of ECU 110, which is a specific means formed by the software and the various hardware resources described above working together. These specific means then perform calculations or processing of information according to the intended use of computer 2000 in this embodiment, thereby constructing a specific ECU 110 according to the intended use.

[0064] A program installed in computer 2000 and causing computer 2000 to function as ECU 111 may act on CPU 2012 or the like to cause computer 2000 to function as each unit of ECU 111. When the information processing described in these programs is read into computer 2000, it functions as each unit of ECU 111, which is a specific means formed by the software and the various hardware resources described above working together. These specific means then perform calculations or processing of information according to the intended use of computer 2000 in this embodiment, thereby constructing a specific ECU 111 according to the intended use.

[0065] A program installed in computer 2000 and causing computer 2000 to function as ECU 112 may act on CPU 2012 or the like to cause computer 2000 to function as each unit of ECU 112. When the information processing described in these programs is read into computer 2000, it functions as each unit of ECU 112, which is a specific means formed by the software and the various hardware resources described above working together. These specific means then perform calculations or processing of information according to the intended use of computer 2000 in this embodiment, thereby constructing a specific ECU 112 according to the intended use.

[0066] Various embodiments have been described with reference to block diagrams. In the block diagrams, each block may represent (1) a stage of a process where an operation is performed or (2) a portion of an apparatus responsible for performing the operation. Particular stages and portions may be implemented by dedicated circuitry, programmable circuitry provided with computer-readable instructions stored on a computer-readable storage medium, and / or a processor provided with computer-readable instructions stored on a computer-readable storage medium. Dedicated circuitry may include digital and / or analog hardware circuitry, and may include integrated circuits (ICs) and / or discrete circuits. Programmable circuitry may include reconfigurable hardware circuitry including logical AND, logical OR, logical XOR, logical NAND, logical NOR, and other logic operations, flip-flops, registers, memory elements such as field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), and the like.

[0067] A computer-readable storage medium may include any tangible device capable of storing instructions that are executed by an appropriate device, such that the computer-readable storage medium with instructions stored thereon constitutes at least a portion of an article of manufacture containing instructions that can be executed to provide means for performing the operations specified in a process or block diagram. Examples of computer-readable storage media may include electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, etc. More specific examples of computer-readable storage media may include floppy disks, diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), electrically erasable programmable read-only memory (EEPROM), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disc (DVD), Blu-ray disc, memory stick, integrated circuit card, etc.

[0068] The computer readable instructions may include either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk®, JAVA®, C++, etc., and conventional procedural programming languages ​​such as the “C” programming language or similar programming languages.

[0069] The computer-readable instructions may be provided to a processor or programmable circuitry of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, either locally or over a wide-area network (WAN) such as a local area network (LAN), the Internet, etc., and executed to provide means for performing the operations specified in the process steps or block diagrams described. Examples of processors include computer processors, processing units, microprocessors, digital signal processors, controllers, microcontrollers, etc.

[0070] Although the present invention has been described above using embodiments, the technical scope of the present invention is not limited to the scope described in the above embodiments. It will be apparent to those skilled in the art that various modifications and improvements can be made to the above embodiments. It is clear from the claims that such modifications and improvements can also be included within the technical scope of the present invention.

[0071] It should be noted that the execution order of each process, such as operations, procedures, steps, and stages, in the devices, systems, programs, and methods shown in the claims, specifications, and drawings is not specifically stated as "before," "prior to," etc., and that the processes can be performed in any order unless the output of a previous process is used in a subsequent process. Even if the operational flow in the claims, specifications, and drawings is described using "first," "next," etc. for convenience, this does not mean that the processes must be performed in this order. [Explanation of symbols]

[0072] 10 vehicles 20 Systems 100 ECU 110 ECU 111 ECU 112 ECU 120 ECU 121 ECU 122 ECU 180 CAN communication network 200 Processing section 220 Authentication Department 240 Control Unit 280 Storage section 2000 Computer 2010 Host Controller 2012 CPU 2014 RAM 2020 Input / Output Controller 2022 Communication Interface 2024 flash memory 2026 ROM 2040 Input / Output Chip

Claims

1. A system including a plurality of in-vehicle devices, the system having a function of determining an abnormality in communication among the plurality of in-vehicle devices by authenticating a message including data, a first counter that is counted each time a power supply is turned on, and a second counter that is incremented over time, an authentication unit that, when authenticating a message including control data exchanged among the plurality of in-vehicle devices, performs authentication on a message including at least the control data and the first counter exchanged among the plurality of in-vehicle devices, using at least the control data and the first counter. Equipped with When checking whether the plurality of in-vehicle devices are synchronized, the authentication unit performs authentication using the second counter without using the first counter for a message that does not include the first counter but includes the second counter and is transmitted and received between the plurality of in-vehicle devices. A system comprising:

2. When checking whether or not the plurality of in-vehicle devices are synchronized, the authentication unit determines that the plurality of in-vehicle devices are not synchronized if a period during which negative authentication results are obtained as authentication results for a plurality of consecutively received messages exceeds a predetermined time. The system of claim 1 .

3. If synchronization among the plurality of on-board devices cannot be confirmed, a control unit controls the vehicle without using the data of the type exchanged among the plurality of on-board devices. The system of claim 1 or 2, further comprising:

4. the plurality of on-board devices include a first on-board device that transmits a message including a yaw rate of the vehicle as data, and a second on-board device that receives the message including the yaw rate as data, When the second in-vehicle device is unable to confirm that synchronization is achieved among the plurality of in-vehicle devices, the second in-vehicle device prohibits the control using the yaw rate and continues the control not using the yaw rate. The system of claim 3 .

5. When control data is transmitted and received between the plurality of in-vehicle devices, the authentication unit performs authentication on a message including the control data, the first counter, and the second counter, which is transmitted and received between the plurality of in-vehicle devices, using the control data, the first counter, and the second counter. A system according to any one of claims 1 to 4.

6. When checking whether or not the plurality of in-vehicle devices are synchronized, the authentication unit determines that the plurality of in-vehicle devices are not synchronized if the number of times that a negative authentication result is obtained as an authentication result for a plurality of consecutively received messages exceeds a predetermined number.

6. A system according to any one of claims 1 to 5.

7. After it is confirmed that the plurality of in-vehicle devices are synchronized, the authentication unit performs authentication on a message including the control data, the first counter, and the second counter, which is transmitted and received between the plurality of in-vehicle devices, using the control data, the first counter, and the second counter. A system according to any one of claims 1 to 6.

8. A vehicle comprising a system according to any one of claims 1 to 7.

9. When an authentication unit provided in the system authenticates a message including control data exchanged between a plurality of on-board devices, the authentication unit performs authentication on a message including at least the control data exchanged between the plurality of on-board devices and a first counter that is counted each time the power of the plurality of on-board devices is turned on, using at least the control data and the first counter; a step in which, when the authentication unit checks whether synchronization is established among the plurality of in-vehicle devices, the authentication unit performs authentication using the second counter without using the first counter for a message that does not include the first counter and that includes a second counter that is incremented over time and that is transmitted and received among the plurality of in-vehicle devices; A method for providing

Images