Control device, control method, and security system

Abstract

Ensuring security when multiple control devices, each with a different unique key, are in use. [Solution] In a control system equipped with multiple control devices in a vehicle, each control device includes a memory for storing a unique key and a controller for performing authentication processing using the unique key. The controller measures the number of control devices among the multiple control devices that have failed to authenticate using the unique key stored in the controller as the failure count. If the failure count of the controller is less than a threshold, the controller transmits the unique key to the control devices among the multiple control devices whose failure count is equal to or greater than the threshold. If the failure count of the controller is equal to or greater than the threshold, the controller does not transmit the unique key.

Description

Technical Field

[0001] The present invention relates to a control device, a control method, and a security system.

Background Art

[0002] In a vehicle equipped with a plurality of ECUs (Electronic Control Units), a method is known in which each ECU holds a unique key unique to each vehicle, and authentication is performed by comparing the unique keys between the ECUs. Thereby, it can be detected that a certain ECU does not hold the same unique key as another ECU, and it can be determined that the ECU has been replaced.

[0003] Also, an ECU can store a common key commonly held by ECUs of the same model number. At this time, a technique is disclosed in which the replaced ECU receives a unique key encrypted using the common key, and decrypts the received unique key using the common key to verify whether the replaced ECU has the correct model number during authentication (see, for example, Patent Document 1).

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, when a plurality of control devices with different unique keys are mixed, security may not be ensured.

[0006] For example, in the case of vehicles that operate unmanned within a factory, the ECUs of multiple vehicles may be integrated into a single vehicle to ensure operational efficiency. This allows, for instance, the use of an ECU from a malfunctioning vehicle to improve the overall operational efficiency of the vehicles. However, in such cases, the unique keys held by each ECU will be different, making secure communication impossible.

[0007] The present invention has been made in view of the above, and aims to ensure security when multiple control devices, each with a unique key, are mixed together. [Means for solving the problem]

[0008] The control device according to the present invention is a control device in a control system that mounts multiple control devices on a vehicle, and comprises a memory for storing a unique key and a controller for performing authentication processing using the unique key. The controller measures the number of control devices among the multiple control devices that have failed to authenticate using the unique key stored in the controller as the failure count. If the failure count of the controller is less than a threshold, the controller transmits the unique key to the control devices among the multiple control devices whose failure count is equal to or greater than the threshold. If the failure count of the controller is equal to or greater than the threshold, the controller does not transmit the unique key. [Effects of the Invention]

[0009] This invention determines whether each control device is functioning correctly based on the results of authentication using unique keys performed between multiple control devices installed in a vehicle, and then provides the necessary control devices with the correct unique keys. This ensures security even when multiple control devices with different unique keys are present. [Brief explanation of the drawing]

[0010] [Figure 1] Figure 1 illustrates the configuration of the security system and the replacement of the ECU. [Figure 2] Figure 2 shows the hardware configuration of the ECU according to the present invention. [Figure 3] Figure 3 shows the software configuration of the controller according to the embodiment. [Figure 4] Figure 4 is a flowchart showing the processing flow of the security system. [Figure 5] Figure 5 is a flowchart showing the flow of the ECU normalization process. [Figure 6] Figure 6 is a sequence diagram showing the processing of multiple ECUs. [Figure 7] Figure 7 illustrates the method for transmitting a unique key. [Figure 8] Figure 8 is a sequence diagram showing the processing of multiple ECUs. [Modes for carrying out the invention]

[0011] Hereinafter, embodiments of the control device, control method, and security system disclosed in this application will be described in detail with reference to the attached drawings. However, the present invention is not limited to the embodiments described below.

[0012] The security system and ECU replacement according to the embodiment will be explained using Figure 1. Figure 1 is a diagram illustrating the configuration of the security system and the replacement of the ECU. For example, the security system 10 is a vehicle or a system mounted on a vehicle. The security system 10 is also an example of a control system.

[0013] As shown in Figure 1(a), the security system 10 includes ECU20_1, ECU20_2, ECU20_3, and ECU20_4.

[0014] An ECU has a unique key written to it at the time of manufacture, shipment, or installation in a vehicle. For example, the unique key may be common to each vehicle model in which the ECU is installed. In Figure 1(a), each ECU has a common unique key. This allows each ECU to communicate securely with each other using their unique keys.

[0015] In (b) of FIG. 1, it is assumed that the ECU 20_4 has failed and stopped operating. Then, in (c) of FIG. 1, the ECU 20_4 is replaced with the ECU 20_5.

[0016] At this time, the unique key held by the ECU 20_5 is assumed to be different from the unique keys held by the ECUs 20_1, 20_2, and 20_3. For example, the ECU 20_5 is taken out from a vehicle of a different vehicle type from the vehicle equipped with the security system 10. In this case, the ECU 20_5 cannot perform secure communication with the ECUs 20_1, 20_2, and 20_3.

[0017] Therefore, the security system 10 of the present embodiment updates the unique key of the ECU 20_5 so that the ECUs 20_1, 20_2, 20_3, and 20_5 can perform secure communication with each other.

[0018] Furthermore, the security system 10 does not require an ECU for centralized management of unique keys, and realizes secure communication by the functions of each ECU. Also, when the security system 10 cannot execute secure communication, it stops operating and ensures security by notifying the user.

[0019] FIG. 2 is a diagram showing the hardware configuration of the ECU according to the embodiment. In the following description, the ECUs 20_1, 20_2, 20_3, 20_4, 20_5, etc. may be referred to as the ECU 20 without distinction. Also, the ECU is an example of a control device.

[0020] As shown in FIG. 2, the ECU 20 includes an interface 21, a controller 22, and a memory 23.

[0021] Interface 21 performs data input and output with other devices. These other devices may be other ECUs or servers. For example, Interface 21 can communicate with other ECUs using CAN (Controller Area Network).

[0022] The controller 22 reads and executes the program stored in memory 23. The controller 22 can be a CPU (Central Processing Unit), DSP (Digital Signal Processor), FPGA (Field Programmable Gate Array), GPU (Graphics Processing Unit), SoC (System on a Chip), etc.

[0023] The controller 22 may be a single processor. The controller 22 may be a multi-processor configuration. Alternatively, the controller 22 may be a multi-core configuration having multiple cores within a single chip connected by a single socket.

[0024] Figure 3 shows the software configuration of the controller according to the embodiment. As shown in Figure 3, the controller 22 has an authentication unit 221, a measurement unit 222, a request unit 223, a provision unit 224, and an update unit 225. In addition to the functions shown in Figure 3, the controller 22 also has functions necessary for vehicle control and the like.

[0025] The authentication unit 221 performs authentication with other ECUs. The authentication unit 221 performs message authentication using a unique key. The unique key is stored in memory 23.

[0026] The measurement unit 222 measures the number of ECUs whose authentication by the authentication unit 221 has failed, i.e., the number of failures. The request unit 223 requests other ECUs or servers to provide a unique key. The provision unit 224 provides the unique key stored in memory 23 to other ECUs. The update unit 225 updates the unique key stored in memory 23. The update unit 225 may also delete the unique key. Deletion of a unique key is achieved, for example, by deleting the unique key.

[0027] Figure 4 is a flowchart showing the processing flow of the security system. The processing shown in Figure 4 may be performed by any of the ECUs shown in Figure 1, or by an ECU that controls the entire security system 10. Here, the security system 10 is assumed to be installed in a vehicle.

[0028] As shown in Figure 4, when the vehicle's main power is turned on (step S11), the security system 10 starts the vehicle's startup process (step S12).

[0029] Here, the security system 10 performs a normalization process for each ECU 20 (step S13). The normalization process for the ECU 20 is carried out by the functions described in Figure 3. Details of the normalization process for the ECU 20 will be explained later using Figure 5.

[0030] If the ECU20 is successfully normalized (step S14; Yes), the security system 10 continues the vehicle startup process (step S17). If the ECU20 is not successfully normalized (step S14; No), the security system 10 cancels the vehicle startup process (step S15) and outputs a warning (step S16). The security system 10 can determine whether the ECU normalization was successful by checking whether authentication using a unique key was successful between all ECUs.

[0031] The following describes an example of the normalization process for each ECU in step S13.

[0032] Figure 5 is a flowchart showing the flow of the ECU normalization process. As shown in Figure 5, the controller 22 performs authentication with other ECUs using a unique key (step S1301). For example, the controller 22 performs message authentication using a unique key stored in memory 23.

[0033] Here, the controller 22 measures the number of ECUs that failed authentication as the failure count (step S1302). From this point onward, the processing branches according to the failure count.

[0034] First, if the number of failures is 0 (step S1303; 0), the controller 22 considers all ECUs to be normal and terminates the process.

[0035] If the number of failures exceeds a threshold (step S1303; threshold or higher), the controller 22 considers its own device to be abnormal and proceeds with the processing from step S1304 onwards. Here, an abnormal ECU means that the device has replaced the ECU, and that its unique key is different from that of a normal ECU that existed in the security system 10 before the replacement. For example, the threshold is 3.

[0036] If the controller 22 determines that its own device is malfunctioning, it discards the unique key (step S1304) and requests another ECU (an ECU other than its own device) to provide the unique key (step S1305). If the controller 22 is able to receive the unique key from another ECU (step S1306; Yes), it retains the provided unique key (step S1308). In other words, the controller 22 writes the provided unique key to memory 23. This allows the controller 22 to obtain the unique key when it determines that a malfunction has occurred.

[0037] On the other hand, if controller 22 is unable to receive a unique key from another ECU (step S1306; No), it requests the server to provide a unique key (step S1307). Then, controller 22 holds the unique key provided by the server (step S1308).

[0038] Furthermore, if the number of failures is below the threshold and there are multiple failures (step S1303), the controller 22 discards the unique key (step S1309) and requests the server to provide a unique key (step S1307). The controller 22 then holds the unique key provided by the server (step S1308).

[0039] Furthermore, if the number of failures is 1 (step S1303; 1), the controller 22 provides a unique key in response to a request from another ECU (step S1310). In other words, an ECU can either provide a unique key or receive one.

[0040] In this way, if the number of failures of its own device is below the threshold, the controller 22 sends a unique key to the ECUs among the multiple ECUs whose number of failures is above the threshold. In other words, the controller 22 determines that its own device is normal when the number of failures of its own device is below the threshold, and sends a signal to the multiple ECUs indicating that its own device is normal.

[0041] Furthermore, the controller 22 does not transmit the unique key if the number of failures of its own device exceeds a threshold. In other words, the controller 22 determines that its own device is abnormal if the number of failures of its own device exceeds a threshold.

[0042] This allows the controller 22 to share unique keys and ensure security when multiple control devices with different unique keys are present.

[0043] Note that step S1306 becomes No in an abnormal ECU if step S1309 is executed in a normal ECU and it becomes impossible to provide the unique key. This occurs, for example, when abnormalities occur simultaneously in multiple ECUs, and it is considered more likely that the security system 10 is under attack than that of simultaneous failures.

[0044] Thus, when the number of failures of its own device is below the threshold, the controller 22 sends a unique key if there is one ECU among the multiple ECUs whose number of failures is equal to or greater than the threshold, but does not send a unique key if there are multiple ECUs whose number of failures is equal to or greater than the threshold. In this way, the controller 22 avoids attacks on the security system 10.

[0045] Furthermore, the fact that there are multiple ECUs with a failure count exceeding a threshold can be generalized to the fact that the number of failures of an ECU exceeding the first threshold is also exceeding the second threshold. For example, the first threshold is 3 and the second threshold is 2, provided that the second threshold is less than or equal to the first threshold.

[0046] Figure 6 is a sequence diagram showing the processing of multiple ECUs. In Figure 6, the security system 10 is assumed to be in state (c) of Figure 1. That is, ECU20_5 is the replaced ECU, and ECU20_1 holds a unique key different from ECU20_2 and ECU20_3. The threshold is 3.

[0047] As shown in Figure 6, ECU20_1 sends data with message authentication to ECU20_2, ECU20_3, and ECU20_5 to perform authentication (steps S101, S102, S103). As a result, authentication is successful (OK) for ECU20_2 and ECU20_3, and fails (NG) for ECU20_5. In this case, the number of failures for ECU20_1 is 1. In the figure, authentication success and failure are represented as OK and NG, respectively.

[0048] Similarly, ECU20_2 and ECU20_5 undergo authentication (steps S104, S105, S106, S107, S108, S109). ECU20_2 has 1 failure. ECU20_5 has 3 failures. Although not shown in the diagram for simplification, ECU20_3 also undergoes authentication. ECU20_3 has 1 failure.

[0049] Since the number of failures exceeds the threshold, ECU20_5 discards the unique key (step S110) and requests ECU20_1 to provide the unique key (step S111). Note that ECU20_5 may randomly select the ECU to request the key from.

[0050] Furthermore, if the number of failures of its own device exceeds a threshold, the controller 22 will notify the user if it is requested to send a unique key. This prevents the sending and receiving of unique keys between ECUs that are deemed abnormal.

[0051] ECU20_1 allows the provision of the unique key because the failure count is 1 (step S112). This means that the failure count was 1 in step S1301 in Figure 5. ECU20_1 sends the encrypted unique key to ECU20_5 (step S113).

[0052] ECU20_5 updates the unique key (step S114). That is, ECU20_5 maintains the unique key by updating memory 23 with the provided unique key.

[0053] Subsequently, ECU20_5 sends data with message authentication to ECU20_1, ECU20_2, and ECU20_3. If authentication is performed, the authentication will be successful in all cases (steps S115, S116, S117).

[0054] Here, memory 23 stores the shared key. The controller 22 decrypts the received unique key using the shared key. This allows the controller 22 to send and receive unique keys in a secure manner.

[0055] Figure 7 illustrates the method for transmitting a unique key. In Figure 7, ECU20_5 requests ECU20_1 to provide a unique key. First, ECU20_5 generates a random number (step S51). Next, ECU20_5 requests the unique key from ECU20_1 and sends the random number (step S52). Subsequently, ECU20_1 uses the common key 32 to encrypt and sign the unique key 31 and the received random number (step S53). Then, ECU20_1 sends the encrypted and signed unique key 31 and random number to ECU20_5 (step S54). At this point, ECU20_5 decrypts and verifies the received unique key 31 and random number (step S55).

[0056] Using Figure 8, we will explain the processing in step S1303 of Figure 5 when the number of failures is below the threshold and there are multiple failures. Figure 8 is a sequence diagram showing the processing of multiple ECUs. In Figure 8, ECU20_5 and ECU20_6 are the replaced ECUs. The threshold is 3.

[0057] As shown in Figure 8, ECU20_1 sends data with message authentication to ECU20_2, ECU20_6, and ECU20_5 to perform authentication (steps S201, S202, S203). As a result, authentication is successful for ECU20_2, but fails for ECU20_6 and ECU20_5. At this time, the number of failures for ECU20_1 is 2. For simplicity, it is not shown in the figure, but ECU20_2 also performs authentication. At this time, the number of failures for ECU20_2 is 2.

[0058] Similarly, ECU20_6 and ECU20_5 perform authentication (steps S204, S205, S206, S207, S208, S209). ECU20_6 has 3 failures. ECU20_5 also has 3 failures.

[0059] Since the number of failures for ECU20_1 is below the threshold and there are multiple failures, the unique key is discarded (step S210). Similarly to ECU20_1, since the number of failures for ECU20_2 is below the threshold and there are multiple failures, the unique key is discarded (step S211).

[0060] ECU20_5 discards its unique key (step S212) because the number of failures exceeds the threshold, and requests ECU20_2 to provide the unique key (step S213). Also, ECU20_6 discards its unique key (step S214) because the number of failures exceeds the threshold, and requests ECU20_1 to provide the unique key (step S215). However, since the unique keys of ECU20_1 and ECU20_2 have been discarded, ECU20_6 and ECU20_5 cannot receive the unique keys.

[0061] ECU20_1, ECU20_2, ECU20_6, and ECU20_5 all obtain a unique key from the server (steps S216, S217, S218, S219). Note that the unique key is not limited to the server; it can be provided by any trusted source.

[0062] Subsequently, if ECU20_1 sends data with message authentication to ECU20_2, ECU20_6, and ECU20_5 and performs authentication, the authentication will be successful in all cases (steps S220, S221, S222). Also, if ECU20_6 sends data with message authentication to ECU20_1, ECU20_2, and ECU20_5 and performs authentication, the authentication will be successful in all cases (steps S223, S224, S225). Also, if ECU20_5 sends data with message authentication to ECU20_6, ECU20_2, and ECU20_1 and performs authentication, the authentication will be successful in all cases (steps S226, S227, S228).

[0063] The security system 10 of this embodiment can improve maintainability by minimizing the effort required for confirmation to the center, etc., in the event of a failure of a single ECU, which is a common occurrence (when the number of failures measured by a normal ECU is 1).

[0064] Furthermore, the security system 10 ensures security by shutting down the system in the event of failures of multiple ECUs that have a low probability of failure but are likely to be under attack (when the number of failures measured by normal ECUs is below a threshold and there are multiple such failures).

[0065] Further effects and modifications can be readily derived by those skilled in the art. Therefore, broader aspects of the present invention are not limited to the specific details and representative embodiments expressed and described above. Accordingly, various modifications are possible without departing from the spirit or scope of the overall concept of the invention as defined by the appended claims and equivalents. [Explanation of Symbols]

[0066] 10 Security Systems 20, 20_1, 20_2, 20_3, 20_4, 20_5, 20_6 ECU 21 Interfaces 22 controllers 23 memory 221 Authentication Department 222 Measurement section 223 Request part 224 Provision Department 225 Update Department

Claims

1. A control device in a control system that has multiple control devices mounted on a vehicle, It comprises a memory for storing a unique key and a controller for performing authentication processing using the unique key, The aforementioned controller, Of the aforementioned plurality of control devices, the number of control devices that failed to authenticate using the unique key stored in the device itself is measured as the number of failures. If the number of failures of the device itself is less than the threshold, the unique key is transmitted to the control device among the plurality of control devices whose number of failures is equal to or greater than the threshold. If the number of failures of the device exceeds the threshold, the unique key will not be transmitted. Control device.

2. The controller determines that its device is malfunctioning if the number of failures of its device exceeds the threshold. The control device according to claim 1.

3. The controller determines that its device is functioning normally if the number of failures of its device is less than the threshold, and transmits a signal indicating that its device is functioning normally to the plurality of control devices. The control device according to claim 1.

4. The controller transmits the unique key if the number of failures of its own device is less than the threshold, and if one of the multiple control devices has a failure count equal to or greater than the threshold. If multiple control devices have a failure count equal to or greater than the threshold, the controller does not transmit the unique key. The control device according to claim 1.

5. If the number of failures of the device itself exceeds a threshold, the controller discards the unique key stored in the device and requests the other control devices among the plurality of control devices to transmit the unique key. The control device according to claim 1.

6. The controller notifies the user if the number of failures of its device exceeds a threshold, or if it is requested to send the unique key. The control device according to claim 1.

7. The aforementioned memory stores the common key, The controller decrypts the received unique key using the shared key. The control device according to claim 1.

8. A controller provided in a control device mounted on a vehicle, which performs authentication processing using a unique key stored in the control device, Of the multiple control devices installed in the vehicle other than the device itself, the number of control devices that failed to authenticate using the unique key stored by the device itself is measured as the number of failures. If the number of failures of the device itself is less than the threshold, the unique key is transmitted to the control device among the plurality of control devices whose number of failures is equal to or greater than the threshold. If the number of failures of the device exceeds the threshold, the unique key will not be transmitted. Control method.

9. A security system having multiple control devices mounted on a vehicle, Each of the aforementioned plurality of control devices includes a memory for storing a unique key and a controller for performing authentication processing using the unique key. The aforementioned controller, Of the aforementioned plurality of control devices, the number of control devices that failed to authenticate using the unique key stored in the device itself is measured as the number of failures. If the number of failures of the device itself is less than the threshold, the unique key is transmitted to the control device among the plurality of control devices whose number of failures is equal to or greater than the threshold. If the number of failures of the device exceeds the threshold, the unique key will not be transmitted. Security system.

Images