Vehicle-mounted relay device

Abstract

To provide a vehicle-mounted relay device capable of enhancing security by verifying data transmitted from a first CPU to a second CPU.SOLUTION: A vehicle-mounted relay device includes a first arithmetic unit that performs data communication with the outside, and a second arithmetic unit that performs data communication with an in-vehicle network and is connected to the first arithmetic unit via a communication line. When the first arithmetic unit transmits data to the second arithmetic unit via the communication line, it generates a message authentication code by encryption using a first common key on the basis of information including the data, and transmits transmission information to the second arithmetic unit via the communication line, with the message authentication code added to the information including the data. When the second arithmetic unit receives transmission information from the first arithmetic unit via the communication line, it decrypts the message authentication code included in the transmission information using a second common key that is the same as the first common key, and uses the decrypted message authentication code to verify whether the transmission information is data intended to attack.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to an in-vehicle relay device. [Background technology]

[0002] In recent years, connected cars, which are vehicles that communicate data between external servers and internal in-vehicle networks such as CAN (Controller Area Network), have become widespread. Because such connected cars are capable of communicating data with the outside, they may be subject to attacks on the internal in-vehicle network from the outside.

[0003] In an in-vehicle network, multiple ECUs (Electronic Control Units) are connected, and these ECUs control various parts such as the engine, brakes, transmission, and airbags. Therefore, if the in-vehicle network is attacked from the outside and the ECU software is hijacked or the control data is tampered with, there is a risk that various parts of the vehicle may malfunction, and in some cases, it may be dangerous to drive. Therefore, such connected cars are provided with a gateway ECU that relays data communication between the outside of the vehicle and the internal in-vehicle network, and the gateway ECU is intended to protect the in-vehicle network from external attacks.

[0004] As a technology using such a gateway ECU, a technology has been disclosed in which two arithmetic devices, a first CPU (Central Processing Unit) and a second CPU, are installed, and an external attack is detected on the first CPU side, which is responsible for communication with the outside world, and whether or not the first CPU has been attacked is determined on the second CPU side, which is responsible for communication with the in-vehicle network (for example, Patent Document 1). [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2022-173923 A Summary of the Invention [Problem to be solved by the invention]

[0006] However, conventional technology does not have a mechanism for verifying whether data sent from the first CPU to the second CPU is data intended for an attack, which may result in insufficient defense against attacks that evade detection and determination.

[0007] The present invention has been made in consideration of the above-mentioned problems, and aims to provide an in-vehicle relay device that can enhance security by verifying data transmitted from a first CPU to a second CPU. [Means for solving the problem]

[0008] In order to solve the above-mentioned problems and achieve the object, the in-vehicle relay device of the present invention is an in-vehicle relay device that relays data communication between an outside world and an in-vehicle network, and comprises a first arithmetic unit that performs data communication with an outside world, and a second arithmetic unit that performs data communication with the in-vehicle network and is connected to the first arithmetic unit via a communication line, wherein when the first arithmetic unit transmits data to the second arithmetic unit via the communication line, the first arithmetic unit generates a message authentication code by encryption using a first common key based on information including the data, and transmits transmission information to the second arithmetic unit via the communication line, with the message authentication code added to the information including the data, and when the second arithmetic unit receives the transmission information from the first arithmetic unit via the communication line, the second arithmetic unit decrypts the message authentication code included in the transmission information using a second common key that is the same as the first common key, and uses the decrypted message authentication code to verify whether the transmission information is data attempting an attack. Effect of the Invention

[0009] According to the present invention, security can be enhanced by verifying data sent from a first CPU to a second CPU. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 is a diagram showing an example of the configuration of an in-vehicle communication system according to the embodiment. [Diagram 2] FIG. 2 is a diagram for explaining an outline of the operation of the in-vehicle communication system according to the embodiment. [Diagram 3] FIG. 3 is a flowchart illustrating an example of a flow of a data transmission process of the first CPU of the gateway ECU according to the embodiment. [Figure 4] FIG. 4 is a flowchart showing an example of a flow of a data reception and verification process of the second CPU of the gateway ECU according to the embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Hereinafter, an embodiment of the vehicle-mounted relay device according to the present invention will be described in detail with reference to Figures 1 to 4. Furthermore, the present invention is not limited to the following embodiment, and the components in the following embodiment include those that a person skilled in the art can easily conceive, those that are substantially the same, and those that are within the scope of what is called equivalent. Furthermore, various omissions, substitutions, modifications, and combinations of the components can be made without departing from the spirit of the following embodiment.

[0012] (Configuration of in-vehicle communication system) 1 is a diagram showing an example of the configuration of an in-vehicle communication system according to an embodiment of the present invention, the configuration of an in-vehicle communication system 1 according to the present embodiment will be described with reference to FIG.

[0013] The in-vehicle communication system 1 shown in Fig. 1 is a system mounted on a vehicle known as a connected car, and performs data communication between an external server or the like and an in-vehicle network 2 that complies with an internal communication protocol such as CAN. As shown in Fig. 1, the in-vehicle communication system 1 includes the in-vehicle network 2, a gateway ECU 3, a TCU (Telematics Control Unit) 4, and a DLC (Data Link Connector) 5.

[0014] The in-vehicle network 2 is an internal network of the vehicle that complies with a communication protocol such as CAN as described above. The in-vehicle network 2 is configured such that a plurality of ECUs (ECUs 7a to 7d in the example shown in FIG. 1) are connected by a bus 6 and are capable of data communication with each other. The ECUs 7a to 7d are control devices for controlling each part. Note that the ECUs 7a to 7d will be simply referred to as "ECU 7" when referring to any ECU or when referring collectively to the ECUs. Examples of ECUs for controlling each part include a fuel injection control ECU that controls fuel injection from an injector to an engine, a transmission control ECU that controls the transmission, and an airbag control ECU that controls an airbag.

[0015] The gateway ECU 3 is a control device that relays data communication between the outside of the vehicle and the in-vehicle network inside the vehicle. Specifically, the gateway ECU 3 relays data communication between the in-vehicle network 2 and the TCU 4 and DLC 5, and relays data communication between each ECU 7 connected to the bus 6 of the in-vehicle network 2. As shown in FIG. 1, the gateway ECU 3 includes a first CPU 10 (first arithmetic unit) and a second CPU 20 (second arithmetic unit), and is connected to the TCU 4, DLC 5, and bus 6. In addition, when data from the outside received by the first CPU 10 via the TCU 4 or DLC 5 is transmitted to the second CPU 20, the gateway ECU 3 has a function of verifying whether the data is data that attempts an attack such as hijacking, spoofing, or retransmission (hereinafter, may be simply referred to as "attack data"). Here, examples of attacks include attempts to take over or spoof using CAN communication commands, or attempts to bring the system down by continuously resending past data.

[0016] The TCU 4 is a communication device for performing data communication with a server 8 of an external service center in response to a request from the first communication control unit 101. The TCU 4 receives data for providing a service to the user from the server 8, for example. The services provided to the user include, for example, a remote service for remotely operating the vehicle, such as activating the air conditioner before getting in, or a vehicle emergency call system (eCall), etc.

[0017] The DLC 5 is a connector for connecting a scan tool 9 in order to perform fault diagnosis of the vehicle based on OBD (On Board Diagnostics).

[0018] The first CPU 10 is a computing device separate from the second CPU 20, to which the TCU 4 and DLC 5 are connected, and which controls data communication with an external device (such as the server 8 or the scan tool 9) via the TCU 4 and DLC 5, and is configured, for example, as a one-chip microcomputer. That is, the first CPU 10 is separated from the in-vehicle network 2 with which the second CPU 20 communicates data, and cannot directly communicate data with the in-vehicle network 2. The first CPU 10 is connected to the second CPU 20 via a communication line X in order to communicate data with the second CPU 20. The first CPU 10 also includes a first communication control unit 101, a second communication control unit 102, a key acquisition unit 103, a counter acquisition unit 104, a MAC (Message Authentication Code) processing unit 105, a memory 106, and an HSM (Hardware Security Module) 107, as shown in FIG. 1.

[0019] The first communication control unit 101 is a functional unit that controls data communication with an external device (such as the server 8 or the scan tool 9) via the TCU 4 and the DLC 5. The first communication control unit 101 is realized, for example, by the first CPU 10 executing a program stored in the memory 106.

[0020] The second communication control unit 102 is a functional unit that controls data communication with the second CPU 20 via the communication line X. As described later, when transmitting data to the second CPU 20 via the communication line X, the second communication control unit 102 transmits information to which counter information and a message authentication code (hereinafter, may be simply referred to as an "authenticator") generated by the MAC processing unit 105 have been added. This data communication via the communication line X between the second communication control unit 102 and the second CPU 20 (the second communication control unit 202 described later) is independent of the internal in-vehicle network 2, and is not subject to the CAN restriction that limits the data length of one frame to a maximum of 8 bytes. As described above, even if the information to which the counter information and the authenticator have been added to the data to be transmitted exceeds 8 bytes, it can be transmitted to the second CPU 20. The second communication control unit 102 is realized, for example, by the first CPU 10 executing a program stored in the memory 106.

[0021] The key acquisition unit 103 is a functional unit that acquires a common key used for encryption for generating an authenticator by the MAC processing unit 105 from the second CPU 20 via the second communication control unit 102. The key acquisition unit 103 stores the acquired common key in the HSM 107. The common key acquired by the key acquisition unit 103 and stored in the HSM 107 corresponds to the "first common key" of the present invention. This allows the first CPU 10 and the second CPU 20 to share the common key. The key acquisition unit 103 is realized, for example, by the first CPU 10 executing a program stored in the memory 106.

[0022] The counter acquiring unit 104 is a functional unit that acquires counter information from the second CPU 20 via the second communication control unit 102. The counter acquiring unit 104 may temporarily store the acquired counter information in the memory 106. The counter acquiring unit 104 is realized, for example, by the first CPU 10 executing a program stored in the memory 106.

[0023] The MAC processing unit 105 is a functional unit that, when transmitting data from the first CPU 10 to the second CPU 20, adds an authenticator called a MAC (Message Authentication Code) to the data and counter information. The MAC processing unit 105 transmits the data and counter information to which the authenticator has been added as transmission information to the first CPU 10 via the second communication control unit 102. Details of the processing by the MAC processing unit 105 will be described later with reference to FIG. 3. The MAC processing unit 105 is realized, for example, by the first CPU 10 executing a program stored in the memory 106.

[0024] The memory 106 is a storage device that stores programs executed by the first CPU 10, control data, hash function information, etc. The memory 106 is formed inside the first CPU 10, which is, for example, a one-chip microcomputer.

[0025] The HSM 107 is a storage device that stores the common key acquired by the key acquisition unit 103. The HSM 107 is a hardware security module configured as hardware to prevent the common key from being acquired from the outside. Therefore, even if the first CPU 10 is attacked from the outside, the common key can be prevented from being leaked. In addition, once the common key acquired by the key acquisition unit 103 is stored in the HSM 107, there is no need to acquire the common key again from the second CPU 20, so that leakage of the common key to the outside caused by repeated transmission and reception of the common key between the first CPU 10 and the second CPU 20 can be prevented. The HSM 107 is formed inside the first CPU 10, which is a one-chip microcomputer.

[0026] In addition, some or all of the first communication control unit 101, the second communication control unit 102, the key acquisition unit 103, the counter acquisition unit 104 and the MAC processing unit 105 may be realized by a hardware circuit (integrated circuit) rather than a software program.

[0027] Moreover, each functional unit of the first CPU 10 shown in Fig. 1 is a conceptual representation of a function, and is not limited to such a configuration. For example, multiple functional units illustrated as independent functional units in the first CPU 10 shown in Fig. 1 may be configured as one functional unit. On the other hand, the function of one functional unit in the first CPU 10 shown in Fig. 1 may be divided into multiple functions and configured as multiple functional units.

[0028] The second CPU 20 is a computing device separate from the first CPU 10, which is connected to the bus 6 of the in-vehicle network 2 and controls data communication and relay processing with each ECU 7 of the in-vehicle network 2, and is configured, for example, by a one-chip microcomputer. The second CPU 20 is also connected to the first CPU 10 via a communication line X in order to perform data communication with the first CPU 10. In this way, by separately mounting the first CPU 10, which performs data communication with the outside, and the second CPU 20, which performs data communication with the internal in-vehicle network 2, as CPUs that control the gateway ECU 3, for example, even if the first CPU 10 is taken over by an attack from the outside, the second CPU 20 can realize a multi-layer defense by discarding data from the first CPU 10 or cutting off the communication path on the communication line X. The second CPU 20 also has a first communication control unit 201, a second communication control unit 202, a key transmission unit 203, a counter generation unit 204, a MAC processing unit 205, and a memory 206, as shown in FIG. 1.

[0029] The first communication control unit 201 is a functional unit that controls data communication or relay processing with each ECU 7 of the in-vehicle network 2. The first communication control unit 201 is realized, for example, by the second CPU 20 executing a program stored in the memory 206.

[0030] The second communication control unit 202 is a functional unit that controls data communication with the first CPU 10 via the communication line X. The second communication control unit 202 is realized, for example, by the second CPU 20 executing a program stored in the memory 206.

[0031] The key transmission unit 203 is a functional unit that transmits a common key previously stored in the memory 206 or a uniquely generated common key to the first CPU 10 via the second communication control unit 202. The common key transmitted by the key transmission unit 203 corresponds to the "second common key" of the present invention. This allows the first CPU 10 and the second CPU 20 to share the common key. When data communication between ECUs is performed by a common key encryption method using such a common key, the common key used in each vehicle needs to be managed by an external server, and when some ECUs are replaced, the common key needs to be distributed again from the outside. On the other hand, the common key shared between the first CPU 10 and the second CPU 20 is used only for data communication between the first CPU 10 and the second CPU 20 in the gateway ECU 3, so there is no need to manage it on an external server, and management costs can be reduced. In addition, since the derivation of the common key shared by the first CPU 10 and the second CPU 20 originates from the second CPU 20, not the first CPU 10 which performs data communication with the outside, it is possible to prevent the common key from being used if the first CPU 10 is taken over. The key transmission unit 203 is realized, for example, by the second CPU 20 executing a program stored in the memory 206.

[0032] The counter generating unit 204 is a functional unit that generates counter information indicating the elapsed time from a predetermined time by utilizing the clock function of the second CPU 20. For example, the counter generating unit 204 transmits the generated counter information at a predetermined timing to the first CPU 10 via the second communication control unit 202. In this way, since the generation of the counter information is initiated not by the first CPU 10 that performs data communication with the outside but by the second CPU 20, even if the first CPU 10 is attacked, the resistance against the attack can be improved. The counter generating unit 204 is realized, for example, by the second CPU 20 executing a program stored in the memory 206.

[0033] The MAC processing unit 205 is a functional unit that verifies whether or not transmission information received from the first CPU 10 via the second communication control unit 202 is attack data, using hash function information and a common key stored in the memory 206. Details of the processing by the MAC processing unit 205 will be described later with reference to Fig. 4. The MAC processing unit 205 is realized, for example, by the second CPU 20 executing a program stored in the memory 206.

[0034] The memory 206 is a storage device that stores programs executed by the second CPU 20, control data, hash function information, a common key, and the like. The hash function information stored in the memory 206 is the same as the hash function information stored in the memory 106. The memory 206 is formed inside the second CPU 20, which is, for example, a one-chip microcomputer. The common key may be stored in an HSM formed inside the second CPU 20.

[0035] In addition, some or all of first communication control unit 201, second communication control unit 202, key transmission unit 203, counter generation unit 204 and MAC processing unit 205 may be realized by a hardware circuit (integrated circuit) rather than a software program.

[0036] Moreover, each functional unit of the second CPU 20 shown in Fig. 1 is shown conceptually, and is not limited to such a configuration. For example, multiple functional units illustrated as independent functional units in the second CPU 20 shown in Fig. 1 may be configured as one functional unit. On the other hand, the function of one functional unit in the second CPU 20 shown in Fig. 1 may be divided into multiple functions and configured as multiple functional units.

[0037] (Overview of the operation of the in-vehicle communication system) 2 is a diagram for explaining an outline of the operation of the in-vehicle communication system according to the embodiment. With reference to FIG. 2, an outline of the operation of the in-vehicle communication system 1 according to the embodiment will be explained.

[0038] As shown in Fig. 2, the key transmission unit 203 of the second CPU 20 transmits a common key previously stored in the memory 206 or a uniquely generated common key to the first CPU 10 via the second communication control unit 202 ("(1) Key transmission" shown in Fig. 2). Then, the key acquisition unit 103 of the first CPU 10 acquires the common key via the second communication control unit 102 and stores it in the HSM 107. This results in the first CPU 10 and the second CPU 20 sharing the common key.

[0039] Furthermore, the counter generation unit 204 of the second CPU 20 uses the clock function of the second CPU 20 to generate counter information indicating an elapsed time from a predetermined time at a predetermined timing, and transmits the counter information to the first CPU 10 via the second communication control unit 202 ("(2) Transmit counter information" shown in FIG. 2). Then, the counter acquisition unit 104 of the first CPU 10 acquires the counter information via the second communication control unit 102.

[0040] When transmitting data from the first CPU 10 to the second CPU 20, the MAC processing unit 105 of the first CPU 10 generates transmission information to which an authenticator is attached for the data and counter information ("(3) Authenticator attachment" shown in Figure 2), and transmits the information to the first CPU 10 via the second communication control unit 102 ("(4) Transmission" shown in Figure 2).

[0041] The MAC processing unit 205 of the second CPU 20 verifies whether the counter information and authenticator contained in the transmission information received from the first CPU 10 via the second communication control unit 202 are attack data or not, using the hash function information and common key stored in the memory 206 ("(5) Verification" shown in Figure 2).

[0042] Hereinafter, the data transmission process by the MAC processing unit 205 will be described in detail with reference to FIG. 3, and the data reception and verification process by the MAC processing unit 105 will be described in detail with reference to FIG.

[0043] (Flow of data transmission process of the 1st CPU) 3 is a flowchart showing an example of the flow of data transmission processing of the first CPU of the gateway ECU 3 according to the embodiment. The flow of data transmission processing of the first CPU 10 of the gateway ECU 3 according to the embodiment will be described with reference to FIG.

[0044] <Step S11> When transmitting data from the first CPU 10 to the second CPU 20, the MAC processing unit 105 of the first CPU 10 hashes the data and the counter information acquired by the counter acquisition unit 104 using the hash function information stored in the memory 106 to obtain a hash value. Then, the process proceeds to step S12.

[0045] <Step S12> The MAC processing unit 105 reads the common key stored in the HSM 107, and encrypts the hash value using the common key, and then the process proceeds to step S13.

[0046] <Step S13> The MAC processing unit 105 adds an encrypted hash value to the plaintext data and counter information as an authenticator, and transmits the resulting information to the second CPU 20 via the communication line X as transmission information.

[0047] The data transmission process of the first CPU 10 is executed by the processes of steps S11 to S13 described above.

[0048] (Flow of data reception and verification process of the 2nd CPU) 4 is a flowchart showing an example of the flow of data reception and verification processing of the second CPU of the gateway ECU 3 according to the embodiment. The flow of data reception and verification processing of the second CPU 20 of the gateway ECU 3 according to the embodiment will be described with reference to FIG.

[0049] <Step S21> The MAC processing unit 205 of the second CPU 20 receives the transmission information from the first CPU 10 via the second communication control unit 202. Then, the process proceeds to step S22.

[0050] <Step S22> The MAC processing unit 205 hashes the plaintext data and counter information of the received transmission information using the hash function information stored in the memory 206 to obtain a hash value, and then proceeds to step S23.

[0051] <Step S23> Furthermore, the MAC processing unit 205 decrypts the encrypted hash value of the received transmission information, using the common key stored in the memory 206. Then, the process proceeds to step S24.

[0052] <Step S24> Then, the MAC processing unit 205 compares whether the hash value hashed in step S22 (first hash value) and the hash value decrypted in step S23 (second hash value) to determine whether they match, and then proceeds to step S25.

[0053] <Step S25> As a result of the comparison by the MAC processor 205, if the two hash values ​​match (step S25: match), the process proceeds to step S26, and if they do not match (step S25: mismatch), the process proceeds to step S28.

[0054] <Step S26> Furthermore, the MAC processing unit 205 compares the counter information included in the transmission information with the information counted by the clock function of the second CPU 20, and judges whether the counter information is abnormal. Here, the counter information is abnormal if, for example, the difference between the information counted by the clock function when the MAC processing unit 205 receives the transmission information and the counter information is equal to or greater than a predetermined time, or if it can be determined that the transmission data is attack data related to a resend attack using old data, etc. Then, the process proceeds to step S27.

[0055] <Step S27> If the counter information of the transmission information is normal (step S27: normal), the data reception / verification process ends, and if the counter information is abnormal (step S27: abnormal), the process proceeds to step S28.

[0056] <Step S28> If the hash values ​​do not match in step S25, it can be determined that the data or counter information included in the transmission information contains unauthorized information due to tampering or the like, and the transmission information can be determined to be attack data. Also, if the counter information is abnormal in step S27, it can be determined that the transmission information is attack data due to a retransmission attack or the like, as described above. Therefore, the MAC processing unit 205 discards the received transmission information. In addition to discarding the transmission information, the MAC processing unit 205 may block communication on the communication line X or leave log data indicating that the attack data has been received. In this way, by discarding the attack data or blocking communication on the communication line X, it is possible to defend against attacks by attack data via the first CPU 10, and the second CPU 20 operates normally, making it possible to ensure the safety of the driving operation of the vehicle.

[0057] By the above-mentioned processing of steps S21 to S28, the data reception and verification processing of the second CPU 20 is executed.

[0058] As described above, in the gateway ECU 3 according to the present embodiment, when the first CPU 10 transmits data to the second CPU 20 via the communication line X, the first CPU 10 generates an authenticator (message authentication code) by encryption using a common key based on information including the data, and transmits the transmission information obtained by adding the message authentication code to the information including the data to the second CPU 20 via the communication line X. When the second CPU 20 receives the transmission information from the first CPU 10 via the communication line X, the second CPU 20 decrypts the authenticator included in the transmission information using the same common key as the common key held by the first CPU 10, and verifies whether the transmission information is data intended for attack using the decrypted authenticator. In this way, since the data transmitted from the first CPU 10 to the second CPU 20 is verified using the message authentication code, security can be enhanced. For example, even if the first CPU 10 is taken over from the outside, it can be verified whether the data transmitted from the first CPU 10 via the communication line X is attack data, so that the second CPU 20 and the in-vehicle network 2 can be protected from the outside. Furthermore, since the common key shared between the first CPU 10 and the second CPU 20 is used only for data communication between the first CPU 10 and the second CPU 20 within the gateway ECU 3, there is no need to manage it on an external server, thereby reducing management costs.

[0059] In the gateway ECU 3 according to this embodiment, the second CPU 20 generates counter information indicating the passage of time and transmits it to the first CPU 10, and when the first CPU 10 transmits data to the second CPU 20 via the communication line X, the first CPU 10 transmits transmission information, which is the data and the counter information received from the second CPU 20 with an authenticator, to the second CPU 20 via the communication line X, and when the second CPU 20 receives transmission information from the first CPU 10 via the communication line X, the second CPU 20 uses the decrypted authenticator to verify whether the transmission information is data intended for an attack and verifies whether the counter information included in the transmission information is abnormal. In this way, even if the first CPU 10 is taken over and an attack is made by resending data using past information to the second CPU 20, the attack can be detected by the abnormality of the counter information.

[0060] In the gateway ECU 3 according to this embodiment, the second CPU 20 transmits a common key (second common key) to the first CPU 10, and the first CPU 10 stores the common key (first common key) received from the second CPU 20 in a hardware security module and uses the common key stored in the hardware security module for encryption. In this way, the derivation of the common key shared by the first CPU 10 and the second CPU 20 starts not from the first CPU 10 that performs data communication with the outside but from the second CPU 20, and the common key is stored by the HSM 107 in the first CPU 10, so that it is possible to prevent the common key from being used if the first CPU 10 is taken over. [Explanation of symbols]

[0061] 1. In-vehicle communication system 2. In-vehicle network 3 Gateway ECU 4 TCU 5 DLC 6 Bus 7, 7a~7d ECU 8 Server 9. Scan Tools 10 1st CPU 20 2nd CPU 101 First communication control unit 102 Second communication control unit 103 Key acquisition part 104 Counter acquisition unit 105 MAC processing unit 106 Memory 107 HSM 201 First communication control unit 202 Second communication control unit 203 Key Transmission Unit 204 Counter Generation Unit 205 MAC Processing Unit 206 Memory X communication line

Claims

1. An in-vehicle relay device that relays data communication between an external device and an in-vehicle network, A first arithmetic unit that performs data communication with an external device; A second arithmetic unit that performs data communication with the in-vehicle network and is connected to the first arithmetic unit via a communication line; Equipped with When transmitting data to the second arithmetic device via the communication line, the first arithmetic device generates a message authentication code by encryption using a first common key based on information including the data, and transmits transmission information, in which the message authentication code is added to the information including the data, to the second arithmetic device via the communication line; When the second calculation device receives the transmission information from the first calculation device via the communication line, the second calculation device decrypts the message authentication code included in the transmission information using a second common key that is the same as the first common key, and uses the decrypted message authentication code to verify whether the transmission information is data intended to attack.

2. the second calculation device generates counter information indicating the passage of time and transmits the counter information to the first calculation device; When the first arithmetic unit transmits the data to the second arithmetic unit via the communication line, the transmission information, in which the data and the counter information received from the second arithmetic unit are added with the message authentication code, is transmitted to the second arithmetic unit via the communication line; The vehicle-mounted relay device described in claim 1, wherein when the second calculation device receives the transmission information from the first calculation device via the communication line, the second calculation device uses the decrypted message authentication code to verify whether the transmission information is data intended to attack, and verifies whether the counter information included in the transmission information is abnormal.

3. The first computing device is when transmitting the data to the second arithmetic device via the communication line, hashing the data and the counter information received from the second arithmetic device to calculate a hash value; encrypting the hash value with the first common key to generate the message authentication code; Transmitting the transmission information in which the message authentication code is added to the data and the counter information; The second calculation device is when receiving the transmission information from the first arithmetic device via the communication line, hashing the data and the counter information included in the transmission information to calculate a first hash value; decrypting the message authentication code included in the transmission information as a second hash value using a second common key that is the same as the first common key; 3. The vehicle-mounted relay device according to claim 2, further comprising: a step of verifying whether the transmitted information is data intended for an attack by comparing the first hash value with the second hash value.

4. The second computing device transmits the second common key to the first computing device; The first computing device stores the second common key received from the second computing device in a hardware security module as the first common key, and uses the first common key stored in the hardware security module for the encryption.An in-vehicle relay device as described in any one of claims 1 to 3.

Images