Log generation device, sensor module, log generation module, and electronic control system

The log generation device verifies event data integrity using hash values, ensuring accurate transmission of logs to enhance cyberattack analysis by preventing tampered data transmission.

JP2025160562APending Publication Date: 2025-10-23DENSO CORP
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
JP2024063142
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-04-10
Publication Date
2025-10-23

AI Technical Summary

Technical Problem

Existing systems fail to verify the integrity of logs generated by security sensors in vehicles, leading to potential tampering and reduced accuracy in analyzing cyberattacks and vulnerabilities due to damaged or tampered logs.

Method used

A log generation device comprising a sensor module and a log generation module that generates and verifies event data using hash values to ensure the integrity of logs before transmission, ensuring only verified logs are sent to other devices.

Benefits of technology

The solution effectively transmits only integrity-verified logs, preventing the spread of corrupted or tampered data and enhancing the accuracy of cyberattack analysis.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025160562000001_ABST
    Figure 2025160562000001_ABST
Patent Text Reader

Abstract

To provide a log generation device, a method, and a program that can verify the integrity of a log.SOLUTION: In a log generation device 100, a sensor module 110 includes an event data generation section that generates event data when detecting the event, a first verification data generation section that generates first verification data for verifying authenticity of the event data, and a first log generation section that generates a security log including the event data and the first verification data, and a log generation module 120 includes a log acquisition section that acquires the security log generated by the sensor module, a second verification data generation section that generates second verification data using the event data included in the security log, and a verification section that verifies identity of the first verification data and the second verification data. The log generation device further comprises a transmission section that transmits the event data when the first verification data and the second verification data are identical.SELECTED DRAWING: Figure 3
Need to check novelty before this filing date? Find Prior Art

Description

[Technical Field]

[0001] The present invention relates to a log generating device mounted on a mobile object such as an automobile, a sensor module and a log generating module possessed by the log generating device, an electronic control system having a log generating device and a log collecting device that collects logs generated by the log generating device, and a method and a program executed by these devices. [Background technology]

[0002] In recent years, technologies for driver assistance and autonomous driving control, including V2X (vehicle-to-vehicle communication) and vehicle-to-infrastructure communication, have been attracting attention. Accordingly, vehicles are increasingly equipped with communication functions, and so-called connected vehicles are becoming more common. As a result, the possibility of vehicles being subject to cyberattacks, such as unauthorized access, is also increasing. If a vehicle is subject to a cyberattack, there is a possibility that data transmitted and received within the vehicle may be tampered with. Therefore, it is necessary to verify the integrity of data transmitted and received within the vehicle, as well as data transmitted and received with the outside of the vehicle.

[0003] For example, Patent Document 1 describes a method in which a communication device constituting an electronic control system calculates a hash value for data to be transmitted to another communication device using an encryption key and a hash function, and generates a data frame including the data to be transmitted and the calculated hash value.The receiving communication device then verifies the hash value in the data frame to confirm the authenticity of the data to be received. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Japanese Patent Application Publication No. 2019-029921 Summary of the Invention [Problem to be solved by the invention]

[0005] Here, the present inventors have found the following problems as a result of detailed investigation. Data transmitted and received by a vehicle includes logs recording abnormalities that occur in the vehicle. Such logs are generated when a security sensor module mounted on an on-board device detects an abnormality and are transmitted to another on-board device via another module mounted on the same device as the security sensor. However, if the log is damaged or tampered with between the time the log is generated by the security sensor and the time it is transmitted to another communication device, incorrect information will be transmitted to the other on-board device. Furthermore, logs recording such abnormalities are typically transmitted to an external device of the vehicle and used to analyze cyberattacks and vulnerabilities of on-board devices. However, if an analysis is performed based on a damaged or tampered log, the accuracy of the analysis may be reduced.

[0006] Therefore, an object of the present invention is to provide a log generating device or the like that can verify the integrity of a log generated by a security sensor. [Means for solving the problem]

[0007] The log generation device of the present disclosure is a log generation device (100, 200, 300, 400) comprising a sensor module (110) and a log generation module (120), wherein the sensor module comprises an event data generation unit (112) that generates event data indicating an event when the event is detected, a first verification data generation unit (113) that generates first verification data for verifying the authenticity of the event data, and a log generation unit (114) that generates a security log including the event data and the first verification data, and the log generation module comprises a log acquisition unit (121) that acquires the security log generated by the sensor module, a second verification data generation unit (122) that generates second verification data using the event data included in the security log, and a verification unit (123) that verifies the identity of the first verification data and the second verification data, and the log generation device further comprises a transmission unit (150) that transmits the event data if the first verification data and the second verification data are identical.

[0008] It should be noted that the claims and the numbers in parentheses attached to the constituent elements of the invention described in this section indicate the correspondence between the present invention and the embodiments described below, and are not intended to limit the present invention. [Effects of the Invention]

[0009] With the above-described configuration, the log generating device etc. of the present disclosure can be configured to transmit only those logs generated by the security sensor whose integrity has been verified to another electronic control device. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 is an explanatory diagram illustrating the arrangement of a log generating device according to each embodiment and its relationship with related devices. [Figure 2] FIG. 1 is a block diagram showing an example of the configuration of an electronic control system according to each embodiment. [Figure 3] FIG. 1 is a block diagram showing an example of the configuration of a log generating device according to a first embodiment. [Figure 4] FIG. 1 is a diagram for explaining a log generated by the sensor module of the first embodiment and verification of the log. [Figure 5] FIG. 1 is a diagram for explaining a log generated by a log generation module according to the first embodiment. [Figure 6] FIG. 1 is a diagram illustrating verification data according to the first embodiment. [Figure 7] FIG. 1 is a diagram illustrating verification data according to the first embodiment. [Figure 8] 1 is a flowchart illustrating the operation of the log generating device according to the first embodiment. [Figure 9] 1 is a flowchart illustrating the operation of the log generating device according to the first embodiment. [Figure 10] FIG. 1 is a block diagram showing an example of the configuration of a log collection device according to a first embodiment. [Figure 11] 1 is a flowchart illustrating the operation of the log collection device according to the first embodiment. [Figure 12] FIG. 10 is a block diagram showing an example of the configuration of a log generating device according to a second embodiment. [Figure 13] FIG. 10 is a diagram for explaining a log generated by a log generating device according to a second embodiment. [Figure 14] 10 is a flowchart illustrating the operation of the log generating device according to the second embodiment. [Figure 15] FIG. 10 is a block diagram showing an example of the configuration of a log generating device according to a third embodiment. [Figure 16] FIG. 10 is a diagram for explaining a log generated by a log generating device according to a third embodiment. [Figure 17] 10 is a flowchart illustrating the operation of the log generating device according to the third embodiment. [Figure 18] FIG. 10 is a block diagram showing an example of the configuration of a log generating device according to a fourth embodiment. [Figure 19] 10 is a flowchart illustrating the operation of a log collection device according to a first modification of each embodiment. [Figure 20] FIG. 10 is a diagram illustrating a log generated by a log generating device according to a second modification of each embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

[0012] The present invention refers to the inventions described in the claims or in the Summary of the Invention section, and is not limited to the following embodiments. Furthermore, at least the words in quotation marks refer to the words described in the claims or in the Summary of the Invention section, and are not limited to the following embodiments.

[0013] The configurations and methods recited in the dependent claims are optional configurations and methods in the inventions recited in the independent claims. The configurations and methods of the embodiments corresponding to the configurations and methods recited in the dependent claims, as well as the configurations and methods recited only in the embodiments without being recited in the claims, are optional configurations and methods in the present invention. The configurations and methods recited in the embodiments when the recitation of the claims is broader than the recitation of the embodiments are also optional configurations and methods in the present invention, in the sense that they are examples of the configurations and methods of the present invention. In either case, by being recited in the independent claims, they become essential configurations and methods of the present invention.

[0014] The effects described in the embodiments are effects obtained when the configurations of the embodiments are provided as examples of the present invention, and are not necessarily effects that the present invention has.

[0015] When there are multiple embodiments, the configurations disclosed in each embodiment are not limited to each embodiment, but can be combined across the embodiments. For example, a configuration disclosed in one embodiment may be combined with another embodiment. Also, configurations disclosed in multiple embodiments may be collected and combined.

[0016] The problem described in the section on the problem to be solved by the invention is not a publicly known problem, but was discovered independently by the inventor, and this fact, together with the configuration and method of the present invention, affirms the inventive step of the invention.

[0017] 1. Configuration underlying each embodiment (1) Location of the log generating device and its relationship with related devices Fig. 1 is a diagram illustrating the arrangement of log generating devices in each embodiment and their relationships with related devices. Note that Fig. 1 illustrates only the log generating device 100 in embodiment 1, but the log generating devices 200, 300, and 400 in embodiments 2 to 4 are also arranged in the same manner as the log generating device 100. Hereinafter, the log generating devices 100, 200, 300, and 400 will be collectively described as the log generating device 100, etc.

[0018] As shown in FIG. 1, the log generating device 100 and the like are electronic control devices that, together with the log collecting device 20, constitute an electronic control system S. Both the log generating device 100 and the log collecting device 20 are "mounted" on a vehicle, which is a "moving body." Note that the electronic control device in each embodiment may be a physically independent electronic control device or a virtualized electronic control device realized using virtualization technology, and will hereinafter be referred to as an ECU (Electronic Control Unit). The configurations of the log generating device 100 and the log collecting device 20 will be described in each embodiment.

[0019] Here, "mobile body" refers to an object that can move at any speed. It also naturally includes cases where the moving body is stationary. Examples include, but are not limited to, automobiles, motorcycles, bicycles, pedestrians, ships, aircraft, and objects mounted on these vehicles. "Mounted" includes not only cases where the device is directly fixed to the mobile body, but also cases where the device is not fixed to the mobile body but moves with the mobile body. For example, cases where the device is carried by a person riding on the mobile body, or cases where the device is mounted on cargo placed on the mobile body, are included.

[0020] The external device 30 is any device provided outside the vehicle, and an example thereof is a Security Operations Center (SOC) that detects and analyzes cyber attacks.

[0021] In FIG. 1, the electronic control system S and the external device 30 are connected via a communication network using a wireless communication method such as IEEE802.11 (Wi-Fi (registered trademark)), IEEE802.16 (WiMAX (registered trademark)), W-CDMA (Wideband Code Division Multiple Access), HSPA (High Speed ​​Packet Access), LTE (Long Term Evolution), LTE-A (Long Term Evolution Advanced), 4G, or 5G. Alternatively, DSRC (Dedicated Short Range Communication) can be used. When the vehicle is parked in a parking lot or in a repair shop, a wired communication method can be used instead of a wireless communication method. For example, a LAN (Local Area Network), the Internet, or a fixed telephone line can be used. Alternatively, the line may be a combination of a wireless communication system and a wired communication system. For example, the electronic control system S and a base station device in a cellular system may be connected by a wireless communication system such as 4G, and the base station device and the external device 30 may be connected by a wired communication system such as a trunk line of a telecommunications carrier or the Internet. A gateway device may be provided at the point of contact between the trunk line and the Internet.

[0022] (2) Configuration of electronic control system S FIG. 2 is a diagram showing an example of the configuration of an electronic control system S. The electronic control system S is made up of multiple ECUs 10 and an in-vehicle network connecting these. FIG. 2 shows eight ECUs (ECU10a to ECU10h) as an example, but the electronic control system S may naturally be made up of any number of ECUs. In the following explanation, when describing one or multiple electronic control devices collectively, they will be referred to as ECU10 or each ECU 10, and when describing individual electronic control devices specifically, they will be referred to as ECU10a, ECU10b, ECU10c, ...

[0023] 2, the ECUs 10 are connected to each other via an in-vehicle communication network such as a Controller Area Network (CAN) or a Local Interconnect Network (LIN). Alternatively, the ECUs 10 may be connected to each other using any communication method, whether wired or wireless, such as Ethernet (registered trademark), Wi-Fi (registered trademark), or Bluetooth (registered trademark). Note that connection refers to a state in which data can be exchanged, and includes not only cases in which different hardware is connected via a wired or wireless communication network, but also cases in which virtual ECUs (also called virtual machines) realized on the same hardware are virtually connected to each other.

[0024] The electronic control system S shown in FIG. 2 includes an integrated ECU 10a, an external communication ECU 10b, zone ECUs (10c, 10d), and individual ECUs (10e to 10h).

[0025] The integrated ECU 10a is an ECU that has a function of controlling the entire electronic control system S and also has a gateway function of mediating communication between the ECUs. The integrated ECU 10a is also called a gateway ECU (G-ECU) or a mobility computer (MC). The integrated ECU 10a may also be a relay device or a gateway device.

[0026] The external communication ECU 10b is an ECU that has a communication unit that communicates with an external device 30 provided outside the vehicle. The communication method used by the external communication ECU 10b is the wireless communication method or wired communication method described above. In order to realize a plurality of communication methods, a plurality of external communication ECUs 10b may be provided. Also, instead of providing the external communication ECU 10b, the integrated ECU 10a may include the functions of the external communication ECU 10b.

[0027] The zone ECUs (10c, 10d) are ECUs equipped with a gateway function that are appropriately arranged according to the location and function of the individual ECUs. For example, the zone ECU 10c is an ECU equipped with a gateway function that mediates communication between the individual ECUs 10e and 10f arranged at the front of the vehicle and other ECUs 10, and the zone ECU 10d is an ECU equipped with a gateway function that mediates communication between the individual ECUs 10g and 10h arranged at the rear of the vehicle and other ECUs 10.

[0028] The individual ECUs (10e to 10h) can be configured with ECUs having any desired functions. Examples include drivetrain electronic control units that control the engine, steering, brakes, etc., body electronic control units that control meters, power windows, etc., information system electronic control units such as navigation systems, and safety control system electronic control units that perform control to prevent collisions with obstacles or pedestrians. Furthermore, the ECUs may be classified as master and slave rather than parallel.

[0029] In the electronic control system S in Fig. 2, each ECU 10 except for ECU 10h is equipped with a security sensor module (hereinafter referred to as a sensor module) (abbreviated as SS in Fig. 2). In this way, it is not necessary for all ECUs 10 constituting the electronic control system S to be equipped with a sensor module. The security log generated by the sensor module will be described later.

[0030] The log generating device 100 and the like in each embodiment will be described as an example of one of the individual ECUs 10e to 100g. However, the log generating device 100 and the like can be provided in any ECU equipped with a sensor module, and may be provided in the integrated ECU 10a, the external communication ECU 10b, or the zone ECUs (10c to 10d).

[0031] In addition, the log collection device 20 in each embodiment will be described as an example where it is the external communication ECU 10b. However, the log collection device may also be provided in the integrated ECU 10a, the zone ECUs (10c to 10d), or the individual ECUs (10e to 10h). When one of the individual ECUs (10e to 10h) is used as the log collection device 20, it is desirable to use a dedicated ECU for realizing the log collection device 20.

[0032] 2. Embodiment 1 (1) Log generating device 100 (a) Configuration of the log generating device 100 An example of the configuration of the log generating device 100 of this embodiment will be described with reference to Fig. 3. The log generating device 100 has a sensor module 110 and a log generating module 120. The log generating device 100 further includes a log saving unit 130 and a setting information saving unit 140, which are memory units, and a transmitting unit 150, which is a communication interface. Note that the log generating device 100, which is an individual ECU, has functions related to the vehicle (for example, functions related to driving the vehicle in the case of a drivetrain electronic control unit), but these are omitted from Fig. 3.

[0033] The sensor module 110, which is also called a security sensor, detects an event and generates a log. The sensor module 110 includes an event detection unit 111, an event data generation unit 112, a first verification data generation unit 113, and a first log generation unit 114.

[0034] The event detection unit 111 detects events that occur in the ECU or the in-vehicle communication network connected to the ECU. For example, when the ECU or the in-vehicle network behaves abnormally due to a cyber-attack, the event detection unit 111 detects the abnormal behavior as an event. The event detection unit 111 may detect not only abnormal behavior but also normal operation as an event.

[0035] When event detection unit 111 detects an event, event data generation unit 112 generates "event data" indicating the detected event. Here, "event data" may be any information relating to an event, and may include not only information indicating the type of event, but also information indicating the location where the event occurred, the sensor that detected the event, the time, etc.

[0036] The first verification data generation unit 113 generates "verification data" (corresponding to "first verification data") for verifying the authenticity of the event data generated by the event data generation unit 112. In this embodiment, a case where the verification data is a hash value will be described as an example, and the hash value generated by the first verification data generation unit 113 is referred to as hash value X.

[0037] Here, "verification data" refers to data for verifying the authenticity of event data, and examples thereof include hash values, CRC values, checksums, or data obtained by encrypting or decrypting these values.

[0038] The verification data is not limited to a hash value, and may be, for example, a CRC, a checksum, or an encrypted hash value, CRC, or checksum. Furthermore, the data used as verification data may be selected depending on the security requirements, error detection rate, and / or processing load required of the log generation device 100. For example, it is known that the processing load required to generate CRCs and checksums is relatively low. Therefore, when verification data with a low processing load is required, CRCs and checksums are used as verification data. In contrast, it is known that hash values ​​and digital signatures have high error detection accuracy, so when high error detection accuracy is required, hash values ​​and digital signatures may be used as verification data.

[0039] Furthermore, the first verification data generation unit 113 does not have to generate a hash value X for all of the event data generated by the event data generation unit 112. The first verification data generation unit 113 determines whether or not to generate verification data for the event data by referring to verification data necessity information stored in the setting information storage unit 140, which will be described later. Then, the first verification data generation unit 113 generates a hash value X only when it determines to generate verification data based on the verification data necessity information.

[0040] The first log generation unit 114 generates a security log (corresponding to a "first security log") including the event data generated by the event data generation unit 112 and the hash value X generated by the first verification data generation unit 113, and stores the generated security log in the log storage unit 130. Hereinafter, the security log generated by the log generation unit 114 will be referred to as log A. Note that in the specifications defined by AUTOSAR (AUTomotive Open System ARchitecture), the security log generated by the sensor module 110 is called SEv.

[0041] Fig. 4 is a diagram showing a specific example of log A generated by first log generator 114. Log A has fields for a sensor ID indicating identification information of a security sensor, an event ID indicating identification information of an event, a counter indicating the number of times the event has occurred, a timestamp indicating the time the event occurred, and context data indicating details of the output of the security sensor. Note that log A shown in Fig. 4 is just an example, and does not necessarily have to have each of the fields shown in Fig. 4.

[0042] In this embodiment, the event data generation unit 112 generates a sensor ID, an event ID, a counter, a timestamp, and context data as event data. The first verification data generation unit 113 generates a hash value X for these data as verification data. The first log generation unit 114 then stores the hash value X in a field of the context data to generate a log A. The hash value X and log A will be described in detail later.

[0043] The log storage unit 130 is a storage unit that stores the log A generated by the first log generation unit 114 of the sensor module 110. The setting information storage unit 140 is a storage unit that stores verification data necessity information indicating whether or not verification data for event data should be generated. The verification data necessity information is stored, for example, in association with an event ID. Therefore, the first verification data generation unit 113 can determine whether or not to generate verification data for the event data by referring to the verification data necessity information associated with the event ID generated by the event data generation unit 112. The setting information storage unit 140 further stores log management information indicating how logs are handled in the log generation module 120. The log management information will be described later.

[0044] The log storage unit 130 and the setting information storage unit 140 may be either an external storage device (hard disk, USB memory, CD / BD, etc.) or an internal storage device (RAM, etc.), and may be either volatile or non-volatile.

[0045] Next, the log generation module 120 will be described. The log generation module 120 is a module that generates a log to be transmitted to the log collection device 20 based on the log generated by the sensor module 110. The log generation module 120 includes a log acquisition unit 121, a second verification data generation unit 122, a verification unit 123, a log processing unit 124, a third verification data generation unit 125, and a second log generation unit 126. The log generation module 120 is also referred to as an IdsM (Intrusion Detection System Manager) in the specifications defined by AUTOSAR.

[0046] The log acquisition unit 121 acquires the log A generated by the sensor module 110 from the log storage unit 130 .

[0047] The second verification data generation unit 122 generates verification data (corresponding to "second verification data") using event data included in the log A acquired by the log acquisition unit 121. Specifically, the second verification data generation unit 122 generates a hash value using data from the log A excluding the hash value X. Hereinafter, the verification data generated by the second verification data generation unit 122 is referred to as hash value Y.

[0048] The verification unit 123 compares the hash value X included in the log A with the hash value Y generated by the second verification data generation unit 122 to "verify the identity" of the hash value X and the hash value Y. Here, "verifying identity" means verifying whether two pieces of verification data can be evaluated as being identical. For example, even if one piece of data is encrypted and the other piece of data is unencrypted, if the unencrypted data or the encrypted data are identical, these pieces of verification data are evaluated as being identical.

[0049] If the verification result of verification unit 123 indicates that hash value X and hash value Y are not identical, log processing unit 124 processes the log based on the log management information stored in setting information storage unit 140. Specifically, if the log management information indicates that logs whose hash values ​​cannot be verified to be identical should be discarded, log processing unit 124 discards log A. Alternatively, if the log management information indicates that logs whose hash values ​​cannot be verified to be identical should be saved, log processing unit 124 may save log A in log saving unit 130 or a storage unit (not shown) provided outside log generating device 100.

[0050] The log processing unit 124 may further process log A that does not contain a hash value. For example, if the verification data necessity information indicates that verification data should be generated for the event data, but log A does not contain verification data, log A may be corrupted or may have been tampered with by a cyber attack. In such a case, the log processing unit 124 may discard log A or store log A based on the log management information.

[0051] On the other hand, if the verification result of the verification unit 123 shows that the hash value X and the hash value Y are the same, the third verification data generation unit 125 generates new verification data (corresponding to "third verification data"). The verification data generated by the third verification data generation unit 125 is verification data for verifying the authenticity of the event data in the log collection device 20 described later. Hereinafter, the verification data generated by the third verification data generation unit 125 is referred to as a hash value α. Note that the verification data generated by the third verification data generation unit 125 is not limited to a hash value.

[0052] The second log generation unit 126 generates a security log to be transmitted to the log collection device 20. Specifically, the second log generation unit 126 generates a security log including event data and the hash value α generated by the third verification data generation unit 125. Hereinafter, the log generated by the second log generation unit 126 is referred to as log B (corresponding to the "second security log"). In the specifications defined by AUTOSAR, the security log generated by the log generation module 120 is called QSEv.

[0053] 5 is a diagram showing a specific example of log B generated by second log generation unit 126. In addition to the same fields as log A, namely, sensor ID, event ID, counter, timestamp, and context data, log B has an ECU ID indicating identification information of ECU 10, which is log generation device 100, a header storing information indicating the protocol version and the state of each field, and a signature field storing hash value α, which is verification data generated by third verification data generation unit 125.

[0054] In this embodiment, the second log generation unit 126 stores the hash value α generated by the third verification data generation unit 125 in the signature field to generate log B. The hash value α and log B will be described in detail later.

[0055] When the log acquisition unit 121 acquires multiple logs A having a common event type, the second log generation unit 126 may generate one log B from the multiple logs A. In this case, the verification unit 123 verifies the verification data for all the logs A, and generates log B from the logs A for which the identity of the verification data has been verified.

[0056] Furthermore, the log generation module 120 in each embodiment has been described as being configured to always generate and transmit log B to the log collection device 20 when hash value X and hash value Y are the same. However, the log generation module 120 may be configured to generate and transmit log B to the log collection device 20 only when event data satisfies a predetermined condition. For example, as described above, the sensor module 110 may detect normal behavior as an event and generate log A. Therefore, the log generation module 120 may generate log B only when the event data indicates an abnormal event. Alternatively, log B may be generated only when the timing at which the event occurred, the frequency at which the event occurred, the number of logs A with a common event type, etc., satisfy predetermined conditions.

[0057] The transmitter 150 transmits the log B generated by the second log generator 126 to the log collection device 20 via the in-vehicle network.

[0058] (b) Generation and verification of validation data Next, with reference to Figures 6 and 7, we will explain the verification data generated by the first verification data generation unit 113, the second verification data generation unit 122, and the third verification data generation unit 125, respectively, and the verification of the identity of the verification data in the verification unit 123.

[0059] Fig. 6(a) is a diagram schematically illustrating event data, which is a sensor ID, an event ID, and context data, generated by the event data generation unit 112. The first verification data generation unit 113 generates a hash value X using the event data shown in Fig. 6(a). Then, the first log generation unit 114 generates a log A shown in Fig. 6(b). As shown in Fig. 6(b), the log A is generated by storing the hash value X generated in Fig. 6(a) in the context data.

[0060] The second verification data generation unit 122 generates a hash value Y based on data from the log shown in Fig. 6(b) excluding the hash value X stored in the context data. Fig. 6(c) shows the hash value Y generated by the second verification data generation unit 122. The verification unit 123 then verifies whether the hash value X stored in the context data and the generated hash value Y are identical.

[0061] Fig. 7(a) is a diagram illustrating a hash value α generated by the third verification data generation unit 125. In this example, the hash value α is generated using the header and ECU ID in addition to the sensor ID, event ID, and event data, which is context data, contained in log A. Then, as shown in Fig. 7(b), log B is generated by storing the hash value α generated in Fig. 7(a) in the signature.

[0062] (c) Operation of the log generating device Next, the operation of the log generating device 100 will be described with reference to Figures 8 and 9. Figures 8 and 9 not only show the log generating method executed by the log generating device 100, but also show the processing procedure of a log generating program that can be executed by the log generating device 100. The order of these processes is not limited to the order shown in Figures 8 and 9. That is, the order may be changed as long as there are no constraints, such as a relationship in which a certain step uses the result of the previous step. The same applies to the diagrams showing the log collection method of the log collecting device 20 and the log generation method in each embodiment, which will be described later.

[0063] FIG. 8 is a diagram illustrating the operation of the sensor module 110 of the log generating device 100. As shown in FIG. When the event detection unit 111 of the sensor module 110 detects an event (S101: Y), the event data generation unit 112 generates event data indicating the event detected in S101 (S102). The first verification data generation unit 113 determines whether or not to generate verification data for the event data generated in S102 by referring to the verification data necessity information stored in the setting information storage unit 140 (S103). If it is determined that verification data should be generated (S103: Y), the verification data generation unit 113 generates a hash value X (S104). The first log generator 114 generates a log A including the event data generated in S102 and the hash value X generated in S104 (S105). The first log generation unit 114 stores the log A generated in S105 in the log storage unit 130 (S106).

[0064] FIG. 9 is a diagram illustrating the operation of the log generating module 120 and the transmitting unit 150 of the log generating device 100. As shown in FIG. The log acquisition unit 121 of the log generation module 120 acquires the log A generated by the sensor module 110 from the log storage unit 130 (S201). Here, if the log A acquired in S201 contains verification data (S202: Y), the second verification data generation unit 122 generates a hash value Y using the event data contained in the log A (S203). The verification unit 123 verifies whether the hash value X included in the log A is the same as the hash value Y generated in S204 (S204). If the verification result in S204 shows that the hash value X and the hash value Y are the same (S205: Y), the third verification data generation unit 125 generates a hash value α (S206). The second log generation unit 126 generates a log B including the event data and the hash value α generated in S206 (S207). Then, the transmission unit 150 transmits the log B generated in S207 to the log collection device 20 (S208). On the other hand, if it is determined in S205 that the hash value X and the hash value Y are not the same (S205: N), the log A is discarded (S209).

[0065] (2) Log collection device (a) Configuration of the log collection device Next, a configuration example of the log collection device 20 will be described with reference to Fig. 10. The log collection device 20 includes a log receiving unit 21, a fourth verification data generation unit 22, a verification unit 23, a log processing unit 24, a third log generation unit 25, and an external communication unit 26. The log collection device 20 is also referred to as an IdsR (Intrusion Detection System Reporter) in the specifications defined by AUTOSAR.

[0066] The log receiving unit 21 receives the log B transmitted from the transmitting unit 150 of the log determining device 100 .

[0067] The fourth verification data generation unit 22 generates verification data (corresponding to "fourth verification data") using event data included in log B received by the log receiving unit 21. Specifically, the fourth verification data generation unit 22 generates a hash value using data other than the signature field from log B. In this embodiment, the hash value is generated using the header, ECU ID, and event data. Hereinafter, the verification data generated by the fourth verification data generation unit 22 is referred to as hash value β.

[0068] The verification unit 23 compares the hash value α included in the log B with the hash value β generated by the fourth verification data generation unit 22 to "verify the identity" of the hash value α and the hash value β.

[0069] If the verification by the verification unit 23 shows that the hash value α and the hash value β are not the same, the log processing unit 24 discards the log B.

[0070] On the other hand, if the verification unit 23 finds that the hash values ​​α and β are identical, the third log generation unit 25 generates a log for external transmission to be transmitted to the external device 30 “based on” the log B. Note that the log for external transmission is a log that notifies the external device 30 that an event has occurred within the electronic control system S, and therefore includes event data indicating the detected event. For example, the third log generation unit 25 aggregates the contents of multiple logs B for which the hash values ​​α and β are determined to be identical, and generates the log for external transmission. Aggregating the contents of the logs B means, for example, combining information contained in each field of the multiple logs B into a single log. By aggregating multiple logs B into a log for external transmission, the amount of data of the logs transmitted from the electronic control system S can be reduced, thereby reducing the communication load between the electronic control system S and the external device 20. Alternatively, the third log generation unit 25 may generate the log for external transmission directly from the log B received by the log receiving unit 21.

[0071] Here, "generating based on" a log includes not only the case where a new log is generated using a log as a log for external transmission, but also the case where a log is used as a log for external transmission as is.

[0072] The external communication unit 26 transmits the log for external transmission generated by the third log generation unit 25 to the external device 30. If the log collection device 20 is provided in an ECU other than the external communication ECU 10b, the log for external transmission is transmitted to the external device 30 via the external communication ECU 10b.

[0073] (b) Log collection device configuration Next, the operation of the log collection device 20 will be described with reference to FIG. The log receiving unit 21 receives the log B transmitted from the log generating module 120 of the log generating device 100 (S301). The fourth verification data generation unit 22 generates a hash value β, which is verification data, using the event data included in the log B received in S301 (S302). The verification unit 23 verifies whether the hash value α included in the log B is identical to the hash value β generated in S302 (S303). Here, if the verification result in S303 shows that the hash value α and the hash value β are the same (S304: Y), the third log generation unit 25 generates a log for external transmission based on the log B (S305). Then, the external communication unit 26 transmits the external transmission log generated in S305 to the external device 30 (S306). On the other hand, if it is determined in S304 that the hash value α and the hash value β are not the same (S304: N), the log B is discarded (S307).

[0074] (3) Summary As described above, according to this embodiment, by performing integrity verification using verification data on the logs generated by the sensor module 110 of the log generating device 100, it is possible to prevent logs that have been corrupted or tampered with by a cyber attack from being sent to the log collecting device.

[0075] 3. Embodiment 2 In the first embodiment, a configuration was described in which the log generation module 120 generates new verification data using event data, stores the generated verification data in a signature, and generates a log. In this embodiment, a configuration will be described in which a log is generated using verification data generated by the sensor module 110. The log generation device of this embodiment will be described below, focusing on the differences from the first embodiment.

[0076] (1) Log generation device (a) Configuration of the log generating device 12 is a diagram illustrating an example of the configuration of the log generating device 200 of this embodiment. The log generating device 200 of this embodiment differs from the log generating device 100 of the first embodiment in that it does not include the third verification data generating unit 125.

[0077] The second log generation unit 126 of this embodiment generates a log B, similar to the first embodiment. However, the verification data included in the log B of this embodiment is either the hash value X generated by the first verification data generation unit 113 or the hash value Y generated by the second verification data generation unit 122. Since the verification unit 123 verifies that the hash value X and the hash value Y are the same, the hash value included in the log B is the same regardless of the value. In this embodiment, a case where a log B including the hash value X is generated will be described as an example.

[0078] In this embodiment, the log generating module 120 does not need to generate a new hash value. As a result, the processing load on the log generating module 120 can be reduced compared to the first embodiment. Also, the hash value X can be stored in the context data, similar to the log A. Therefore, the log B in this embodiment does not need to have a signature field. Therefore, the data amount of the log B is smaller compared to the first embodiment, and the communication load between the ECUs 10 can be reduced.

[0079] (b) Logs generated by the log generating device Next, logs A and B of this embodiment will be described with reference to Fig. 13. Fig. 13(a) shows multiple logs A1 to An generated by the first log generation unit 114 of the sensor module 110 and acquired by the log acquisition unit 121 of the log generation module 120. Logs A1 to An generated by the same sensor module 110 and having a common event type share a common sensor ID and event ID. However, the value stored in the counter indicating the number of times an event has occurred differs for each log. Therefore, in Fig. 13(a), the values ​​stored in the counter are indicated by c1, c2, ... cn. Furthermore, the timestamp indicating the time when an event occurred also differs for each log.

[0080] In this embodiment, the first verification data generation unit 113 of the sensor module 110 generates a hash value X1 based on the values ​​of the fields excluding the counter, and the first log generation unit 114 stores the generated hash value X1 in the context data to generate a log A1. The same applies to logs A2 and An. As described above, logs A1 to An share the same sensor ID and event ID, but the timestamp values ​​are different for each log. Therefore, the hash values ​​X1 to Xn stored in each log are different values.

[0081] FIG. 13(b) shows log B generated by the second log generation unit 126 of the log generation module 120 based on logs A1 to An. As in the first embodiment, a header and an ECU ID are added to log B. Furthermore, the counter of log B stores the sum (C) of the counter values ​​(c1 to cn) of logs A1 to An used to generate log B. Here, in the example shown in FIG. 13(b), log B stores the same sensor ID, event ID, timestamp, and hash value as log An. As such, log B includes event data (corresponding to "specific event data") included in log An (corresponding to "specific security log"), which is the newest log among the multiple logs generated by the sensor module 110, and hash value Xn included in log An. Note that in FIG. 13(b), log B stores hash value Xn, which was included in log An, but may store hash value Yn generated by the second verification data generation unit 122 instead of hash value Xn.

[0082] 13, an example has been described in which log B is generated including data stored in the most recent log An among the logs generated by the sensor module 110. However, instead of the most recent log An, log B may be generated including data stored in the oldest log (i.e., log A1) among the logs generated by the sensor module 110.

[0083] (c) Operation of the log generating device Next, the operation of the log generating module 120 of the log generating device 200 of this embodiment will be described with reference to Fig. 14. The same processes as those in the first embodiment are denoted by the same reference numerals as in Fig. 9, and the description thereof will be omitted.

[0084] In this embodiment, if the result of verifying the identity of the hash values ​​is that the hash values ​​X and Y are identical (S205: Y), a log B is generated without generating a hash value α (S207). Here, the hash value included in the log B generated in S207 is either the hash value X or the hash value Y.

[0085] (2) Log collection device The log collecting device 20 of this embodiment operates in the same manner as the log collecting device 20 of embodiment 1. However, while embodiment 1 verifies the identity of hash value α included in the signature of log B and hash value β generated by the fourth verification data generating unit 22 of the log collecting device 20, this embodiment verifies the identity of hash value X or hash value Y included in the context data of log B and the hash value generated by the fourth verification data generating unit 22. The hash value generated by the fourth verification data generating unit 22 of this embodiment is assumed to be hash value Z. The fourth verification data generating unit 22 generates hash value Z using the sensor ID, event ID, and timestamp of log B, and verifies the identity of hash value X or hash value Y and hash value Z.

[0086] (3) Summary As described above, according to this embodiment, the hash value used for identity verification in the log generation module 120 can be reused for identity verification in the log collection device 20, thereby reducing the processing load on the log generation module 120.

[0087] 4. Embodiment 3 In the first and second embodiments, the log generating module 120 is configured to always verify the identity of the verification data when the verification data is included in the acquired log. In the present embodiment, a configuration is described in which it is determined whether or not to verify the identity of the verification data depending on the importance of the log.

[0088] The log generating device 300 of this embodiment will be described with reference to Fig. 15. The log generating device 300 of this embodiment differs from the log generating devices of the first and second embodiments in that it includes an importance storage unit 301. For example, the importance storage unit 301 stores an event ID that identifies an event and an importance level set for the event, in association with each other. Here, multiple importance levels may be associated with the same event depending on the state of the vehicle, etc. For example, when the vehicle is stopped, a low importance level may be associated with the event ID, whereas when the vehicle is moving, a high importance level may be associated with the same event ID.

[0089] In this embodiment, when the first log generation unit 114 generates log A, importance data indicating the importance associated with the event in the importance storage unit 301 is stored in the context data in addition to the hash value X. The importance data is data that "indicates" the "importance" set according to the event detected by the event data generation unit 112. Fig. 16 is a diagram schematically illustrating log A in this embodiment. The context data includes the hash value X and the importance data.

[0090] Here, "importance" is an index classified based on a predetermined evaluation standard, and the number of classifications may be plural. "Indicating" the level of importance may refer to information that directly indicates the level of importance, or may refer to information that indirectly indicates the level of importance.

[0091] When log acquisition unit 121 of log generation module 120 acquires log A, it determines whether or not to perform identity verification according to the importance data included in the context data. Specifically, if the importance indicated by the importance data is "higher" than a predetermined importance, second verification data generation unit 122 determines to perform identity verification and generates second verification data. On the other hand, if the importance indicated by the importance data is lower than the predetermined importance, second verification data generation unit 122 determines not to perform identity verification and does not generate second verification data. The term "than" encompasses both cases where the value is the same as the value of the comparison target and cases where the value is not the same as the value of the comparison target.

[0092] In the above example, importance data is stored in log A. However, importance data may not be stored in log A, and second verification data generation unit 122 may refer to importance storage unit 301 to determine the importance of log A. Specifically, when log acquisition unit 121 acquires log A, it refers to importance storage unit 301 to acquire the importance associated with the event ID included in log A. If the "importance" associated with the event ID is "higher" than a predetermined importance, it is determined that identity verification should be performed. On the other hand, if the importance indicated by the importance data is lower than the predetermined importance, it is determined that identity verification should not be performed.

[0093] Next, the operation of the log generating module 120 of the log generating device 300 of this embodiment will be described with reference to Fig. 17. The same processes as those in the first embodiment are denoted by the same reference numerals as in Fig. 9, and the description thereof will be omitted.

[0094] In this embodiment, when the context data includes verification data (S202), it is further determined whether the importance of the event indicated by the event data included in log A is higher than a predetermined importance (S211). Here, when the importance is higher than the predetermined importance (S211: Y), the second verification data generation unit 122 generates second verification data (S203).

[0095] According to this embodiment, it is possible to verify the identity of verification data only for events with high importance, thereby reducing the processing load on the log generating device and preventing logs containing high-importance event data from being transmitted to the log collecting device if the logs are corrupted or tampered with by a cyber attack.

[0096] 5. Embodiment 4 In this embodiment, a configuration will be described in which identity verification using verification data is performed depending on the processing load of the log generating device.

[0097] A log generating device 400 of this embodiment will be described with reference to Fig. 18. The log generating device 400 of this embodiment differs from the log generating devices of embodiments 1 to 3 in that the log generating module 120 has a load determining unit 401. The load determining unit 401 determines the processing load of the log generating device 400.

[0098] The second verification data generation unit 122 changes the frequency at which it generates second verification data depending on the processing load of the log generation device 400 determined by the load determination unit 401. As a result, the frequency at which the verification unit 123 performs identity verification also changes. Here, the frequency at which the verification unit 123 performs identity verification is lower when the processing load is high (corresponding to the "first processing load") than when the processing load is low (corresponding to the "second processing load"). For example, when the processing load of the log generation device 400 determined by the load determination unit 401 is higher than a predetermined value, the second verification data generation unit 122 reduces the frequency at which it generates second verification data. As a result, the frequency at which the verification unit 123 performs identity verification is reduced. Specifically, the second verification data is not generated for all logs A acquired by the log acquisition unit 121, but, for example, second verification data is generated for only one log A out of two logs A acquired by the log acquisition unit 121, thereby reducing the frequency at which identity verification is performed.

[0099] Generating verification data and verifying identity are processes that require a relatively large amount of calculation, and place a heavy processing load on the log generating device. According to this embodiment, by changing the frequency of identity verification depending on the processing load of the log generating device 400, it is possible to prevent the processing load on the log generating device 400 from becoming significantly high.

[0100] 6. Variations (1) Variation 1 In the above-described first embodiment, the log generating module 120 generates a log by storing verification data used by the log collecting device 20 to verify the log in a signature, and in the second embodiment, the log generating module 120 generates a log by storing the verification data in context data instead of a signature. In this modification, the log generating module 120 selects whether to store the verification data in a signature or in context data.

[0101] The configuration of the log generating device of this modified example is the same as that of the log generating device 100 of embodiment 1. However, in this modified example, the second log generating unit 126 determines whether to store the verification data in the signature or the context data depending on, for example, the content of the event or the security sensor that detected the event, and generates the log B described in embodiment 1 or embodiment 2.

[0102] The configuration of the log collecting device of this modified example is also similar to that of the log collecting device 20 described in embodiment 1 or embodiment 2. However, when the log receiving unit 21 of the log collecting device 20 of this modified example receives log B, it determines whether to use the verification data stored in the signature or the context data for verification.

[0103] For example, the verification unit 23 of the log collection device 20 determines whether to use the verification data stored in the signature or the context data, based on the sensor ID or event ID stored in log B. Alternatively, the context data of log B may store information indicating the field in which the verification data is stored. In this case, the verification unit 23 determines whether to use the verification data stored in the signature or the context data, based on this information.

[0104] The data used to generate the verification data differs between the first and second embodiments. For example, in the first embodiment, as shown in FIG. 7(a), the hash value α is generated using data from the header to the context data, whereas in the second embodiment, as shown in FIG. 13(b), the hash value Xn is generated using only predetermined data (e.g., a sensor ID, an event ID, and a timestamp). Therefore, the log collecting device 20 also differs in which of the fields included in the log B the data included in the field is used to generate the verification data. In this modification, the data used by the fourth verification data generating unit 22 of the log collecting device 20 to generate the verification data differs depending on whether the verification data is stored in the signature or the context data. Therefore, in this modification, it is necessary to determine whether the verification data is stored in the signature or the context data of the log B.

[0105] 19 is a diagram illustrating an example of the operation of the log collection device 20 in this modification. In this modification, when log B is received from the log generation device 100 (S301), it is determined whether or not to perform verification using the verification data stored in the signature of log B (S311). If it is determined that verification using the signature is to be performed (S311: Y), a hash value β is generated based on data stored in a field other than the signature of log B (S302), and identity verification is performed (S303), as in the first embodiment. On the other hand, if it is determined that verification using the signature is not to be performed (S311: N), a hash value Z is generated (S312), as in the second embodiment. Then, identity verification is performed between hash value X or Y included in the context data and hash value Z (S303).

[0106] (2) Variation 2 In the above-described embodiment, a case where a hash value is used as verification data has been described as an example. In this modified example, a case where a digital signature is used as verification data will be described.

[0107] A case where a signature is generated as verification data will be described with reference to Fig. 20. As shown in Fig. 20(a), the first verification data generation unit 113 generates a hash value X using event data, as in the above-described embodiment. However, in this modification, the first verification data generation unit 113 further encrypts the generated hash value X with a private key to create a digital signature. Then, the first log generation unit 114 generates log A shown in Fig. 20(b). As shown in Fig. 20(b), log A is generated by storing the digital signature generated in Fig. 20(a) in context data.

[0108] When the log acquisition unit 121 acquires log A, the second verification data generation unit 122 generates a hash value Y based on data from log A shown in Fig. 20(b) excluding the digital signature stored in the context data. Fig. 20(c) shows the hash value Y generated by the second verification data generation unit 122. The second verification data generation unit 122 also decrypts the digital signature stored in the context data with the public key to generate a hash value X. The verification unit 123 then verifies the identity of the hash value X generated by decrypting the digital signature and the hash value Y generated using the event data.

[0109] (3) Variation 3 In the above-described embodiment, the log processing unit 124 discards or saves the log if the hash value X and the hash value Y are not identical, based on the log management information saved in the setting information saving unit 140. In this modified example, the log management information is stored in the log A, and the log processing unit 124 may discard or save the log if the hash value X and the hash value Y are not identical, based on the log management information included in the log A.

[0110] In this modification, when generating log A, the first log generation unit 114 stores in the context data log management information indicating how to process the log if hash value X and hash value Y are not identical. Then, if the verification unit 123 verifies the identity of the verification data and finds that the verification data are not identical, the log processing unit 124 discards or saves log A based on the log management information stored in the context data of log A.

[0111] 7. Summary The features of the log generating device and the like in each embodiment of the present invention have been described above.

[0112] The terms used in each embodiment are merely examples and may be replaced with synonymous terms or terms having the same functions.

[0113] The block diagrams used to explain the embodiments classify and organize the device configuration by function. The blocks representing each function can be realized by any combination of hardware or software. Furthermore, because they represent functions, the block diagrams can also be understood as disclosures of method inventions and program inventions that realize the methods.

[0114] The order of the functional blocks that can be understood as the processes, flows, and methods described in each embodiment may be changed as long as there are no constraints, such as one step utilizing the results of another step that precedes it.

[0115] The terms first, second, through Nth (N is an integer) used in each embodiment and in the claims are used to distinguish between two or more configurations or methods of the same type, and do not limit the order or superiority or inferiority.

[0116] Furthermore, examples of the configuration of the log generating device of the present invention include the following. Examples of the component include semiconductor elements, electronic circuits, modules, and microcomputers. Examples of semi-finished products include an electronic control unit (ECU) and a system board. Finished product forms include mobile phones, smartphones, tablets, personal computers (PCs), workstations, and servers. Other examples include devices with communication functions, such as video cameras, still cameras, and car navigation systems.

[0117] Furthermore, necessary functions such as an antenna and a communication interface may be added to the log generating device.

[0118] In addition, the present invention can be realized not only by dedicated hardware having the configuration and functions described in each embodiment, but also by a combination of a program for realizing the present invention recorded on a recording medium such as a memory or hard disk, and general-purpose hardware having a dedicated or general-purpose CPU and memory that can execute the program.

[0119] A program stored in a non-transitory physical recording medium (for example, an external storage device (hard disk, USB memory, CD / BD, etc.) or an internal storage device (RAM, ROM, etc.)) of dedicated or general-purpose hardware can be provided to the dedicated or general-purpose hardware via a recording medium, or via a communication line from a server without using a recording medium. This makes it possible to always provide the latest functions through program upgrades. [Industrial Applicability]

[0120] Although the log generating device of the present disclosure has been described as being primarily an on-board electronic control device mounted on an automobile, it can be applied to any moving object, such as a motorcycle, a ship, a train, an airplane, etc. It may also be a device that is not mounted on a moving object. [Explanation of symbols]

[0121] 100, 200, 300, 400 Log generation device, 110 Sensor module, 112 Event data generation unit, 113 First verification data generation unit, 114 First log generation unit, 120 Log generation module, 121 Log acquisition unit, 122 Second verification data generation unit, 123 Verification unit, 125 Third verification data generation unit, 126 Second log generation unit, 150 Transmission unit, 301 Importance storage unit, 401 Load determination unit, 20 Log collection device, 21 Log reception unit, 22 Fourth verification data generation unit, 23 Verification unit, 26 External communication unit

Claims

1. A log generating device (100, 200, 300, 400) comprising a sensor module (110) and a log generating module (120), The sensor module includes: an event data generating unit (112) that generates event data indicating an event when the event is detected; a first verification data generation unit (113) that generates first verification data for verifying the authenticity of the event data; a log generation unit (114) that generates a security log including the event data and the first verification data, The log generation module: a log acquisition unit (121) that acquires the security log generated by the sensor module; a second verification data generation unit (122) that generates second verification data using the event data included in the security log; a verification unit (123) that verifies the identity of the first verification data and the second verification data, The log generating device further includes a transmitting unit (150) that transmits the event data when the first verification data and the second verification data are identical. Log generator.

2. a first log generation unit that is the log generation unit generates a first security log that is the security log; The log generation module further comprises: a second log generating unit (126) that generates a second security log including the event data and third verification data for verifying the authenticity of the event data when the first verification data and the second verification data are identical; the transmitting unit transmits the second security log. The log generating device according to claim 1 .

3. the log generation module further includes a third verification data generation unit (125) that generates the third verification data different from the first verification data and the second verification data using the event data. The log generating device (100) of claim 2.

4. the third verification data is either the first verification data or the second verification data; The log generating device (200) of claim 2.

5. the log acquisition unit acquires a plurality of first security logs having a common event type indicated by the event data; the second security log includes specific event data, which is event data included in a specific security log that is the oldest or newest security log among the plurality of first security logs, and the third verification data, which is either the first verification data included in the specific security log or the second verification data generated using the specific event data; The log generating device according to claim 2.

6. the security log further includes importance data indicating an importance level set according to the event; the verification unit verifies the identity when the importance indicated by the importance data is higher than a predetermined importance. The log generating device (300) of claim 1.

7. The log generating device further comprises an importance storage unit (301) that stores the events in association with importance levels set according to the events, the verification unit verifies the identity when the importance level corresponding to the event indicated by the event data included in the security log is higher than a predetermined importance level. The log generating device (300) of claim 1.

8. The log generation module further includes a load determination unit (401) that determines the processing load of the log generation device, When the processing load is a first processing load, the verification unit verifies the identity less frequently than when the processing load is a second processing load that is lower than the first processing load. The log generating device (400) of claim 1.

9. the transmission unit transmits the event data when the first verification data and the second verification data are identical and the event data satisfies a predetermined condition. The log generating device according to claim 1 .

10. The transmission unit transmits the event data to a log collection device (20) mounted on a moving body together with the log generation device, The log collection device a log receiving unit (21) that receives the second security log from the log generating device; a fourth verification data generation unit (22) that generates fourth verification data using the event data included in the second security log; a verification unit (23) that verifies the identity of the third verification data and the fourth verification data included in the second security log; an external communication unit (26) that transmits an external transmission log including the event data generated based on the second security log to the outside of the mobile body when the third verification data and the fourth verification data are identical; The log generating device according to claim 2 .

11. an event data generating unit (112) that generates event data indicating an event when the event is detected; a first verification data generation unit (113) that generates first verification data for verifying the authenticity of the event data; a log generating unit (114) that generates a security log including the event data and the first verification data; A sensor module (110) comprising:

12. A log generating module (120) mounted on a log generating device (100, 200, 300, 400) together with a sensor module (110), a log acquisition unit (121) that acquires a security log generated by the sensor module and including event data indicating an event detected by the sensor module and first verification data for verifying the authenticity of the event data; a second verification data generation unit (122) that generates second verification data using the event data included in the security log; a verification unit (123) that verifies the identity of the first verification data and the second verification data; A log generation module comprising:

13. An electronic control system mounted on a moving body and having a log generating device (100) and a log collecting device (20), The log generating device an event data generating unit (112) that generates event data indicating an event when the event is detected; a first verification data generation unit (113) that generates first verification data for verifying the authenticity of the event data; a log generating unit (114) that generates a security log including the event data and the first verification data; a sensor module (100) having a log acquisition unit (121) that acquires the security log generated by the sensor module; a second verification data generation unit (122) that generates second verification data using the event data included in the security log; a verification unit (123) that verifies the identity of the first verification data and the second verification data; a second log generating unit (126) that generates a second security log including the event data and third verification data for verifying the authenticity of the event data when the first verification data and the second verification data are identical; a log generation module (120) having: a transmitting unit (150) that transmits the second security log, The log collection device a log receiving unit (21) that receives the second security log from the log generating device; a fourth verification data generation unit (22) that generates fourth verification data using the event data included in the second security log; a verification unit (23) that verifies the identity of the third verification data and the fourth verification data included in the second security log; an external communication unit (26) that transmits an external transmission log including the event data generated based on the second security log to the outside of the mobile body when the third verification data and the fourth verification data are identical; Electronic control system.

14. A log generation method executed in a log generation device (100, 200, 300, 400) including a sensor module (110), a log generation module (120), and a transmission unit (150), comprising: The sensor module includes: When an event is detected, generating event data indicating the event; generating first verification data for verifying authenticity of the event data; generating a security log including the event data and the first verification data; The log generation module: Acquire the security log generated by the sensor module; generating second verification data using the event data included in the security log; Verifying the identity of the first verification data and the second verification data; the transmission unit transmits the event data when the first verification data and the second verification data are identical. Log generation method.

15. A log generation method executed by a sensor module (110) mounted on a log generation device, comprising: When an event is detected, generating event data indicating the event; generating first verification data for verifying authenticity of the event data; generating a security log including the event data and the first verification data; Log generation method.

16. A log generation program executable by a sensor module (110) mounted on a log generation device, When an event is detected, generating event data indicating the event; generating first verification data for verifying authenticity of the event data; generating a security log including the event data and the first verification data; a log generating program that causes the sensor module to execute a process including:

17. A log generation method executed by a log generation module (120) mounted in a log generation device (100, 200, 300, 400) together with a sensor module (110), comprising: acquiring a security log generated by the sensor module and including event data indicating an event detected by the sensor module and first verification data for verifying authenticity of the event data; generating second verification data using the event data included in the security log; verifying the identity of the first verification data and the second verification data; Log generation method.

18. A log generation program executable by a log generation module (120) mounted in a log generation device (100, 200, 300, 400) together with a sensor module (110), acquiring a security log generated by the sensor module and including event data indicating an event detected by the sensor module and first verification data for verifying authenticity of the event data; generating second verification data using the event data included in the security log; verifying the identity of the first verification data and the second verification data; a log generating program that causes the log generating module to execute a process including:

19. A log collection method executed in an electronic control system mounted on a moving body and having a log generating device (100) and a log collecting device (20), comprising: The log generating device includes a sensor module (110), a log generating module (120), and a transmitting unit (150); The sensor module includes: When an event is detected, generating event data indicating the event; generating first verification data for verifying authenticity of the event data; generating a security log including the event data and the first verification data; The log generation module: Acquire the security log generated by the sensor module; generating second verification data using the event data included in the security log; Verifying the identity of the first verification data and the second verification data; generating a second security log including the event data and third verification data for verifying authenticity of the event data when the first verification data and the second verification data are identical; the transmitting unit transmits the second security log; The log collection device receiving the second security log from the log generating device; generating fourth verification data using the event data included in the second security log; verifying the identity of the third verification data and the fourth verification data included in the second security log; If the third verification data and the fourth verification data are identical, an external transmission log including the event data generated based on the second security log is transmitted to an outside of the mobile body. Log collection method.

Citation Information

Patent Citations

  • Transmitter, receiver, and communication method

    JP2019029921A