Data storage device, mobile body, and data storage program

Abstract

A data storage device (100) stores protection target data (TD) using a block chain (BC). The data storage device (100) comprises: a storage processing unit (72) that stores a first hash value of the protection target data in a secure storage (TS) of a secure world (SW) to which access from a normal world (NW) is restricted; a block generation request unit (73) that requests generation of a block which is connected to the block chain and which is based on the protection target data; and a block generation unit (52) that calculates a second hash value of the protection target data according to the request from the block generation request unit, and generates the block if the first hash value and the second hash value match.

Description

Data storage device, mobile object, and data storage program CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application is based on Japanese Application No. 2023-208385, filed on December 11, 2023, the contents of which are incorporated herein by reference.

[0002] The present disclosure relates to a data storage device, a mobile object, and a data storage program.

[0003] In recent years, the importance of data acquired by moving objects such as vehicles has increased. Therefore, there is a demand for a device that can store data acquired by moving objects such as vehicles while ensuring reliability.

[0004] Patent Document 1 describes a data storage device in which an on-board ECU stores data acquired in a vehicle using a blockchain. In the data storage device described in Patent Document 1, a block generation unit generates one block based on a predetermined specified number or capacity of log data.

[0005] Japanese Patent Application Laid-Open No. 2021-13122

[0006] As such, in the data storage device described in Patent Document 1, blocks are generated when the log data reaches a predetermined number or capacity, so blocks cannot be generated at a time when immediate block generation is desired, such as in the event of an accident.

[0007] In view of the above background, the present disclosure aims to provide a data storage device, a mobile object, and a data storage program that are capable of securely generating blocks based on data to be protected at the timing when the protection is desired.

[0008] The present disclosure employs the following technical solutions to solve the above problems. The reference symbols in parentheses in the claims and in this section are merely examples showing the correspondence with the specific solutions described in the embodiments below as one aspect, and do not limit the technical scope of the present disclosure.

[0009] A data storage device of one embodiment of the present disclosure is a data storage device used in a mobile body that stores protected data acquired by the mobile body using a blockchain, and includes a storage processing unit that stores a first hash value of the protected data in secure storage in a secure world where access from the normal world is restricted, a block generation request unit that requests the generation of a block based on the protected data and is linked to the blockchain, and a block generation unit that calculates a second hash value of the protected data upon request from the block generation request unit and generates the block if the first hash value and the second hash value match.

[0010] According to this configuration, if the first hash value of the protection target data stored in the secure storage matches the second hash value of the protection target data calculated in response to a request from the block generation request unit, a block is generated based on the protection target data. Therefore, a block can be securely generated in response to a block generation request from the block generation request unit.

[0011] A mobile object according to one aspect of the present disclosure includes the above-described data storage device.

[0012] A data storage program of one embodiment of the present disclosure is a data storage program used in a mobile body that stores protected data acquired by the mobile body using a blockchain, and causes a computer to function as a storage processing unit that stores a first hash value of the protected data in secure storage in a secure world where access from the normal world is restricted, a block generation request unit that requests the generation of a block based on the protected data and is linked to the blockchain, and a block generation unit that calculates a second hash value of the protected data upon request from the block generation request unit and generates the block if the first hash value and the second hash value match.

[0013] The above and other objects, features, and advantages of the present disclosure will become more apparent from the following detailed description taken in conjunction with the accompanying drawings, in which Fig. 1 is a block diagram showing the electrical configuration of an in-vehicle ECU according to an embodiment together with related in-vehicle configurations, Fig. 2 is a flowchart showing details of logger processing performed by a logger, and Fig. 3 is a flowchart showing the flow of processing executed by the in-vehicle ECU according to an embodiment for securely generating a block based on data to be protected at a timing when protection is desired.

[0014] Hereinafter, embodiments of the present disclosure will be described with reference to the drawings. Note that the embodiments described below are examples of how the present disclosure may be implemented, and the present disclosure is not limited to the specific configurations described below. When implementing the present disclosure, specific configurations according to the embodiments may be appropriately adopted.

[0015] FIG. 1 is a block diagram showing the electrical configuration of an on-board ECU (Electronic Control Unit) 100 according to an embodiment of the present disclosure, together with related on-board configurations. The functions of the data storage device shown in FIG. 1 are implemented in the on-board ECU 100. The on-board ECU 100 is one of multiple electronic control units mounted on a vehicle A, which is an example of a moving body. The on-board ECU 100 may be, for example, an integrated body ECU or an autonomous driving ECU for autonomous driving or advanced driving assistance. Furthermore, the on-board ECU 100 may be a dedicated ECU for storing acquired data. The on-board ECU 100 is directly or indirectly electrically connected to a DCM (Data Communication Module) 40, a V2X (Vehicle to Everything) communication device 30, an on-board sensor 20 including multiple types of sensors, and the like.

[0016] The DCM 40 is a communication module mounted on the vehicle A. The DCM 40 transmits and receives radio waves to and from base stations around the vehicle A via wireless communication conforming to communication standards such as LTE (Long Term Evolution) and 5G. The DCM 40 enables collaboration between the cloud CLD and in-vehicle devices (Cloud to Car). By mounting the DCM 40, the vehicle A becomes a connected car that can connect to the Internet. The DCM 40 transmits a backup of data stored in the in-vehicle ECU 100 to a backup server BS installed on the cloud CLD. In addition, the DCM 40 receives the backup data stored in the backup server BS.

[0017] The V2X communication device 30 is an in-vehicle communication device that realizes vehicle-to-vehicle communication, roadside-to-vehicle communication, and pedestrian-to-vehicle communication. The V2X communication device 30 is capable of bidirectional communication with in-vehicle devices mounted on other vehicles, roadside devices installed on roads, mobile devices carried by pedestrians, and the like, when they are within its communication range. The V2X communication device 30 is capable of transmitting communication data acquired through communication to the in-vehicle ECU 100, for example, via a communication bus of an in-vehicle communication network.

[0018] The on-vehicle sensors 20 include multiple types of sensors mounted on the vehicle A. The on-vehicle sensors 20 include a speed sensor and an inertial sensor (Inertial Measurement Unit, IMU) that detect the driving state of the vehicle A. The on-vehicle sensors 20 include an in-vehicle camera, a pedal sensor, and a steering sensor that detect the driver's state and driving operation. The on-vehicle sensors 20 include an outside camera, a millimeter-wave radar, and a lidar that are used for driving assistance or autonomous driving. The on-vehicle sensors 20 can transmit detection data to the on-vehicle ECU 100, for example, via a communication bus of an on-vehicle communication network.

[0019] The on-board ECU 100 is an on-board computer that functions as a data storage device that acquires data generated in the vehicle A and stores the acquired data as log data LD in a tamper-resistant state. The on-board ECU 100 is mainly composed of a control circuit including a processor 11, a RAM (Random Access Memory) 12, a storage unit 13, an input / output interface 14, etc.

[0020] The processor 11 is hardware for arithmetic processing coupled to the RAM 12, and can execute various programs by accessing the RAM 12. The storage unit 13 includes a non-volatile storage medium, and stores various programs executed by the processor 11. The storage unit 13 stores at least a data storage program related to the accumulation, provision, and monitoring of log data LD generated in the vehicle A.

[0021] The in-vehicle ECU 100 defines at least two different processing areas within the system: a normal world network (NW) and a secure world software (SW). The normal world network (NW) and the secure world software (SW) may be physically separated on the hardware, or may be virtually separated by cooperation between hardware and software. As an example, the in-vehicle ECU 100 uses a function such as a context switch to separate resources required for application execution into the normal world network (NW) and the secure world software (SW).

[0022] The normal world NW is a normal area where an operating system and applications are executed. The normal world NW is provided with a normal storage US as a storage area (untrusted storage) for storing data.

[0023] The secure world SW is an area isolated from the normal world NW. In the secure world SW, a secure operating system and applications for processes requiring security are executed. Access from the normal world NW to the secure world SW is restricted by the functions of the processor 11. Therefore, the existence of the secure world SW cannot be recognized from the normal world NW, ensuring the safety of processes executed in the secure world SW and information stored in the secure world SW. The secure world SW is provided with a secure storage TS as a storage area (Trusted Storage) for storing data. The capacity of the secure storage TS may be smaller than the capacity of the normal storage US.

[0024] The in-vehicle ECU 100 of this embodiment stores acquired data using a blockchain BC. The in-vehicle ECU 100 of this embodiment also performs a logger process for storing log data LD, an EDR process for securely storing data TD (hereinafter sometimes referred to as "protected data") in association with the blockchain BC at the timing when the data is to be protected, a data provision process for providing the log data LD accumulated by the logger process and / or the EDR process to an external device, and a system monitoring process for monitoring the system status. As functional units for performing each of the above processes, the in-vehicle ECU 100 is provided with a logger 50, an EDR (Event Data Recorder) 70, and an auditor 60 that operate in the normal world NW, and an observer 80 that operates in the secure world SW.

[0025] The logger 50 is a functional unit that executes logger processing to associate various data generated in the vehicle A with the blockchain BC and store the data. The logger 50 has functional units such as a data acquisition unit 51, a block generation unit 52, a data storage unit 53, and a hash value storage unit 54.

[0026] The data acquisition unit 51 is electrically connected to, for example, a communication bus of an in-vehicle communication network. The data acquisition unit 51 can acquire various data generated in the vehicle A, such as communication data and detection data, through the communication bus. The data acquisition unit 51 extracts preset data from the data sequentially output to the communication bus by the in-vehicle sensors 20 and the V2X communication device 30, selectively acquires the data as acquired data to be saved, and saves it in the normal storage US as log data LD.

[0027] The block generation unit 52 has a function of calculating a hash value using a hash function such as SH-256. The block generation unit 52 uses the hash function to convert the log data LD into a hash chain-like data structure. The block generation unit 52 creates one block based on a predetermined specified number or capacity of log data LD. The block generation unit 52 inputs the data of one block into the hash function and includes the resulting hash value in the next block, thereby generating a blockchain BC made up of a large number of blocks linked in a linear chain.

[0028] The block generation unit 52 calculates a hash value to be stored as main data in each block based on the specified number or capacity of log data LD acquired by the data acquisition unit 51. The block generation unit 52 may individually calculate a hash value for each of the multiple log data LD, or may calculate a Merkle root of the multiple log data LD. Note that in this embodiment, a hash value is stored as main data in each block, but the log data LD itself may be stored in each block instead of the hash value of the log data LD.

[0029] The data storage unit 53 stores the log data LD acquired by the data acquisition unit 51 in a specified file path in the normal storage US. The data storage unit 53 stores the data of the blockchain BC generated by the block generation unit 52 in the normal storage US. The data storage unit 53 stores linking information Lin that links a specific block with the file path of the log data LD included in that specific block in the normal storage US.

[0030] The hash value storage unit 54 can update the block hash value HvB and block number NoB stored in the secure storage TS by executing a predetermined command (e.g., a secure monitor call) that enables access to the secure world SW. The block hash value HvB is a hash value based on the current final block LB of the blockchain BC. The block hash value HvB is a 256-bit value (character string) obtained as the output by an arithmetic process in which all data in the final block LB is input into a hash function.

[0031] The block number NoB is a unique value assigned to the last block LB, and indicates the number of the block in the blockchain BC of the current last block LB when the initial block is "0." The block number NoB also indicates the number of blocks currently linked to the blockchain BC. The hash value storage unit 54 updates the block hash value HvB and block number NoB of the secure storage TS every time the block generation unit 52 generates a new block AB and calculates its hash value.

[0032] The details of the logger processing performed by the logger 50 will be described below based on the flowchart shown in Fig. 2 and with reference to Fig. 1. The logger processing starts when power supply to the in-vehicle ECU 100 starts, and continues until power supply ends.

[0033] In step S101, the block generation unit 52 determines whether an initial block of the blockchain BC has already been generated in the normal storage US. If it is determined in step S101 that the initial block exists in the normal storage US, the flow proceeds to step S105. On the other hand, if it is determined in step S101 that the initial block does not exist in the normal storage US, the flow proceeds to step S102, where initial processing is performed.

[0034] In step S102, the block generation unit 52 calculates a hash value based on any data and generates an initial block for storing the hash value. The data storage unit 53 stores the generated initial block in the normal storage US.

[0035] In step S103, the block generation unit 52 calculates a hash value of the initial block set in step S102.

[0036] In step S104, the hash value storage unit 54 stores the hash value calculated in step S103 in the secure storage TS as the initial value of the block hash value HvB. Additionally, in step S104, the hash value storage unit 54 records "0" as the initial value in the address of the secure storage TS where the block number NoB is stored.

[0037] In step S105, the data acquisition unit 51 starts the process of acquiring data to be accumulated as log data LD.

[0038] In step S106, the data acquisition unit 51 determines whether the data to be saved has been acquired. If the data to be saved has not been acquired, the process of repeating the determination in step S106 waits for the occurrence of the relevant data. Then, when the data acquisition unit 51 acquires the data to be saved from the communication bus, the flow proceeds from step S106 to step S107.

[0039] In step S107, the data storage unit 53 stores the acquired data as log data LD in a specific storage area of ​​the normal storage US in accordance with the instruction of the file path.

[0040] In step S108, the block generation unit 52 calculates a hash value of the log data LD stored in step S107. In steps S106 and S108, the acquisition of the log data LD and the calculation of the hash value are performed sequentially, thereby distributing the processing load over time.

[0041] In step S109, the block generation unit 52 determines whether the log data LD to be stored in the new block AB has reached a specified number or a specified capacity. If the block generation unit 52 determines in step S109 that the log data LD has not reached the specified number or the specified capacity, the flow returns to step S106, and the data acquisition unit 51 continues collecting the log data LD. On the other hand, if the block generation unit 52 determines in step S109 that the log data LD has reached the specified number or the specified capacity, the flow proceeds to step S110. Note that in step S109, the elapsed time since the previous generation of the new block AB may be counted, and the flow may proceed to step S110 when a predetermined elapsed time has elapsed (timeout).

[0042] In step S110, the block generation unit 52 generates a new block AB that includes at least a hash value based on the current last block LB and a hash value of the log data LD calculated in step S108. The new block AB is stored in the normal storage US by the data storage unit 53 and linked to the blockchain BC as a new last block LB.

[0043] In step S111, the data storage unit 53 generates linking information Lin and stores the linking information Lin in the normal storage US. The linking information Lin is information that links the new block AB generated in step S110 with a file path that specifies the storage destination of the log data LD whose hash value is included in the new block AB.

[0044] In step S112, the block generation unit 52 calculates the hash value of the new block AB.

[0045] In step S113, the hash value storage unit 54 updates the block hash value HvB of the secure storage TS using the hash value calculated in step S112. Additionally, in step S113, the hash value storage unit 54 increments the value of the block number NoB recorded in the secure storage TS to match the block number of the new block AB. By repeating the above steps S106 to S113, the storage of the log data LD associated with the blockchain BC is realized.

[0046] In this way, the logger 50 stores the log data LD in association with the blockchain BC. However, as described above, when it is determined that the log data LD has reached a designated number or a designated capacity, or when a predetermined amount of time has elapsed since the previous generation of a new block AB, the block generation unit 52 of the logger 50 generates a new block AB based on the log data LD. In this way, when the logger 50 stores the log data LD in association with the blockchain BC, the timing of generating a new block AB is left to the block generation unit 52. For this reason, the logger 50 cannot block the log data LD when it is desired to generate a block immediately, such as in the event of an accident.

[0047] Therefore, the in-vehicle ECU 100 of this embodiment further includes an EDR 70 as a functional unit for dividing the log data LD into blocks when a block needs to be generated immediately, such as in the event of an accident. The EDR 70 is a functional unit that executes EDR processing in cooperation with the logger 50 and an observer 80 (described later) to associate and store protected data TD generated in vehicle A in the blockchain BC when protection is needed. The EDR 70 is, for example, a drive recorder, and can record data related to an accident when vehicle A has an accident. The EDR 70 can record data from a predetermined time before the accident occurred to a predetermined time after the accident occurred. Furthermore, for example, the EDR 70 may record vehicle information, including vehicle speeds before and after a collision or near-collision of vehicle A involving the deployment of an airbag or the like, as time-series data, in addition to when an accident occurs in vehicle A. The EDR 70 has at least functional units such as a target data acquisition unit 71, a storage processing unit 72, and a block generation request unit 73.

[0048] The target data acquisition unit 71 is electrically connected to, for example, a communication bus of an in-vehicle communication network. The target data acquisition unit 71 can acquire, via the communication bus, protection target data TD to be protected from various data generated in vehicle A, such as communication data and detection data. The target data acquisition unit 71 acquires the protection target data TD from data sequentially output to the communication bus by the in-vehicle sensors 20 and the V2X communication device 30, and stores the data in the normal storage US as log data LD. The target data acquisition unit 71 acquires the protection target data TD when a predetermined action occurs with respect to vehicle A, for example, when an accident occurs with vehicle A, when vehicle A engages in reckless driving, when there is another vehicle driving recklessly around vehicle A, such as meandering or cutting in. This allows the acquired protection target data TD to be acquired at a desired timing, i.e., when a predetermined action occurs with respect to vehicle A, and stored using a blockchain.

[0049] For example, when the speed of vehicle A detected from the output of the speed sensor exceeds a predetermined level, the target data acquisition unit 71 may determine that the vehicle is driving at an abnormal speed, and acquire protected data TD from a predetermined time before the speed of vehicle A exceeds the predetermined speed to a predetermined time after the speed of vehicle A exceeds the predetermined speed.

[0050] In addition, the target data acquisition unit 71 may detect the driver's state and driving operation from the output of, for example, an in-vehicle camera, a pedal sensor, or a steering sensor, and in a specified case, determine that the driver's state or driving operation is abnormal and acquire the protected data TD.

[0051] In addition, the target data acquisition unit 71 may determine that vehicle A is in an abnormal driving state, such as running out of control or spinning, and acquire the protected data TD, for example, when the vibration level of vehicle A detected from the output of the inertial sensor becomes equal to or exceeds a predetermined vibration level, or when the direction of vehicle A detected from the output of the inertial sensor changes suddenly.

[0052] In addition, the target data acquisition unit 71 may detect other vehicles that are driving recklessly around vehicle A from the output of, for example, an outside vehicle camera, radar, or lidar, and acquire the protection target data TD.

[0053] The storage processing unit 72 stores the protection target data TD acquired by the protection target data acquisition unit 71 as log data LD in a specified file path within the normal storage US. The storage processing unit 72 calculates a target data hash value HvT (hereinafter sometimes referred to as a "first hash value") of the protection target data TD acquired by the protection target data acquisition unit 71, transmits the target data hash value HvT to the secure world SW, to which access from the normal world NW is restricted, and stores the target data hash value HvT in the secure storage TS of the secure world SW. The storage processing unit 72 has a function for calculating a hash value using a hash function such as SH-256. Preferably, when the protection target data TD is generated, the storage processing unit 72 stores the protection target data TD in the normal storage US as log data LD by specifying a file path, and stores the target data hash value HvT of the protection target data TD in the secure storage TS. The target data hash value HvT is the hash value of the protection target data TD calculated when the protection target data TD is generated. In this way, by immediately storing the target data hash value HvT in the secure storage TS at the time the protected data TD is generated, the possibility of abnormalities such as tampering or loss occurring in the protected data TD is reduced, making it easier to ensure the accuracy of the target data hash value HvT stored in the secure storage TS.

[0054] The block generation request unit 73 requests the block generation unit 52 of the logger 50 to generate a block based on the protected data TD acquired by the protected data acquisition unit 71, which will be linked to the end of the blockchain BC. In response to the request from the block generation request unit 73, the block generation unit 52 calculates a hash value (hereinafter sometimes referred to as a "second hash value") of the protected data TD to be stored as main data in a block newly generated based on the protected data TD acquired by the protected data acquisition unit 71. The block generation unit 52 generates a block based on the protected data TD when the hash value determination unit 82 (described later) determines that this second hash value matches the target data hash value HvT (first hash value). If the first hash value and the second hash value do not match, the block generation unit 52 does not generate a block and discards the protected data TD. In this way, by generating a block only when the first hash value and the second hash value match, only correct protected data TD that has not been tampered with or has been deleted can be securely blocked. Although the hash value of the protection target data TD is stored in each block, the protection target data TD itself may also be stored in each block. The block generation unit 52 then calculates the hash value of a new block AB based on the newly generated protection target data TD.

[0055] The data storage unit 53 of the logger 50 stores, in the normal storage US, linking information Lin that links a block based on the protection target data TD generated by the block generation unit 52 with the file path of the protection target data TD included in that block. Note that the process of storing this linking information Lin in the normal storage US may be executed by the storage processing unit 72 of the EDR 70.

[0056] The hash value storage unit 54 of the logger 50 updates the block hash value HvB of the secure storage TS using the hash value of the new block AB based on the protection target data TD calculated by the block generation unit 52. In addition, the hash value storage unit 54 increments the value of the block number NoB recorded in the secure storage TS to match the block number of the new block AB.

[0057] The auditor 60 is a functional unit that executes a data provision process for providing the log data LD accumulated by the logger 50 and / or the EDR 70 to the user U, and a data maintenance process related to the backup and restoration of the log data LD. The auditor 60 has a data provision unit 61 and a data verification unit 62 as functional units related to the data provision process.

[0058] The data providing unit 61 can communicate with a user interface UI external to the in-vehicle ECU 100 via wired or wireless communication. The user interface UI is, for example, an HMI device mounted on the vehicle A, or a user terminal such as a smartphone, tablet, or personal computer. A user U inputs a user operation to the user interface UI to refer to the log data LD. The user interface UI outputs a reference request to the data providing unit 61 based on the user operation.

[0059] The data providing unit 61 receives a reference request output by the user interface UI. The reference request specifies the file path of the log data LD that the user U wishes to reference. The data providing unit 61 extracts the file path of the acquired reference request and provides the file path to the data verifying unit 62. If there is no problem with the verification result by the data verifying unit 62, the data providing unit 61 returns the log data LD specified by the file path to the user interface UI that is the source of the reference request.

[0060] The data verification unit 62, triggered by the receipt of a reference request by the data provider 61, verifies abnormalities, including whether or not the specific log data LD (requested data) requested in the reference request has been tampered with, using the block hash value HvB stored in the secure storage TS. The data verification unit 62 identifies the block number linked to the file path specified in the reference request based on the linking information Lin. The data verification unit 62 recalculates each hash value based on the log data LD for the identified block (hereinafter sometimes referred to as the "specific block SB") and blocks newer than the specific block SB, and verifies the consistency of the blockchain BC.

[0061] The data verification unit 62 determines whether there is an abnormality in the log data LD based on whether the hash value based on the recalculated last block LB matches the block hash value HvB stored in the secure storage TS. If the recalculated hash value of the last block LB matches the block hash value HvB, the data verification unit 62 determines that there is no abnormality such as tampering in the log data LD. On the other hand, if the recalculated hash value of the last block LB does not match the block hash value HvB, the data verification unit 62 determines that there is a possibility of an abnormality such as tampering in the log data LD.

[0062] 1, the auditor 60 has, as functional units related to data maintenance processing, a backup transmission unit 63 and a data restoration unit 64. The backup transmission unit 63 and the data restoration unit 64 cooperate with the DCM 40 to enable sharing of log data LD with the backup server BS.

[0063] The backup transmission unit 63 detects the generation of a new block AB by the block generation unit 52. When the new block AB is generated by the block generation unit 52, the backup transmission unit 63 transmits backup data of a large amount of log data LD whose hash values ​​are stored in the new block AB to an external backup server BS. The backup server BS associates the backup data transmitted from the backup transmission unit 63 with ID information of the in-vehicle ECU 100 and stores the data in a large-capacity storage medium such as a hard disk drive.

[0064] In a situation where communication by DCM 40 is not possible, backup transmission unit 63 suspends transmission of log data LD to backup server BS. In this case, when DCM 40 returns to a communication-enabled state, backup transmission unit 63 resumes transmission of the unsent backup data.

[0065] The data restoration unit 64 detects an abnormality determined by the data verification unit 62. When an abnormality such as tampering or loss occurs in the log data LD or the like and the data verification unit 62 determines that the log data LD is abnormal, the data restoration unit 64 restores the log data LD using backup data stored in the backup server BS. The data restoration unit 64 requests the backup server BS to transmit backup data for multiple log data LD in which hash values ​​are incorporated in each block after the specific block SB that was verified by the data verification unit 62. The data restoration unit 64 regards the backup data received from the backup server BS as normal log data LD and overwrites the log data LD specified by the file path with the corresponding backup data. Note that the data restoration unit 64 may also acquire all backup data from the backup server BS and perform a process of updating all log data LD.

[0066] The observer 80 operates in the secure world SW, and is therefore protected from tampering from outside the in-vehicle ECU 100 and from the normal world NW. The observer 80 is a functional unit that monitors the status of the logger 50, EDR 70, and auditor 60 in the normal world NW from the secure world SW. The observer 80 has at least functional units such as a hash value determination unit 81 and a file monitoring unit 82.

[0067] The hash value determination unit 81 operates in the secure world SW. The hash value determination unit 81 determines whether a first hash value (the target data hash value HvT) and a second hash value (a hash value to be stored as data body in a block newly generated based on the protection target data TD acquired by the protection target data acquisition unit 71 in response to a request from the block generation request unit 73) match, and returns the determination result to the block generation unit 52 of the logger 50. By having the hash value determination unit 81 operate in the secure world SW, there is no risk of the executable file of the hash value determination unit 81 being tampered with. This ensures the accuracy of the determination result of the hash value determination unit 81, enabling secure block generation. Furthermore, by performing a comparison of the hash value of the protection target data TD within the data storage device, blocking can be performed quickly, easily, and securely.

[0068] The file monitoring unit 82 operates in the secure world SW and starts system monitoring processing at a predetermined interval, for example, for periodic monitoring. Operating the file monitoring unit 82 in the secure world SW eliminates the risk of tampering with the executable files of the file monitoring unit 82. The file monitoring unit 82 determines whether the executable files of the logger 50 required to execute the logger processing, the executable files of the EDR 70 required to execute the EDR processing, and the executable files of the auditor 60 required to execute the data provision processing and data maintenance processing have been tampered with. As a result, even if the logger 50, the EDR 70, and the auditor 60 are each operated in the normal world NW, the correct operation of these files is ensured by the file monitoring unit 82 operating in the secure world SW. Furthermore, because each executable file, which tends to be large, can be stored in the normal storage US of the normal world NW, it is possible to accurately verify whether each executable file has been tampered with while reducing the amount of data stored in the secure storage TS.

[0069] The file monitoring unit 82 acquires these executable files from the normal world NW. The executable files of the logger 50 are, in other words, executable files associated with the data acquisition unit 51, block generation unit 52, data storage unit 53, and hash value storage unit 54, respectively. Similarly, the executable files of the EDR 70 are, in other words, executable files associated with the target data storage unit 71, storage processing unit 72, and block generation request unit 73, respectively. The executable files of the auditor 60 are, in other words, executable files associated with the data provision unit 61, data verification unit 62, backup transmission unit 63, and data restoration unit 64, respectively. The file monitoring unit 82 comprehensively acquires the entirety of each executable file. The executable files include, for example, binary files. Furthermore, compilers, linkers, libraries, etc. may also be included in the executable files.

[0070] The file monitoring unit 82 inputs each executable file into a hash function in a predetermined order, and calculates a hash value for the logger 50, a hash value for the EDR 70, and a hash value for the auditor 60, respectively.

[0071] Hash values ​​based on initial executable files that are guaranteed not to have been tampered with are stored as monitoring hash values ​​in the secure storage TS. Specifically, a logger hash value HvL based on the executable file of a normal logger 50, an EDR hash value HvE based on the executable file of a normal EDR 70, and an auditor hash value HvA based on the executable file of a normal auditor 60 are stored in the secure storage TS as monitoring hash values. By storing the logger hash value HvL, the EDR hash value HvE, and the auditor hash value HvA in the secure storage TS, they are protected from tampering due to access from outside and the normal world NW.

[0072] The file monitoring unit 82 determines whether the hash value based on the executable file of the logger 50 acquired in the current system monitoring process matches the logger hash value HvL stored in the secure storage TS. Similarly, the file monitoring unit 82 determines whether the hash value based on the executable file of the EDR 70 acquired in the current system monitoring process matches the EDR hash value HvE stored in the secure storage TS. Similarly, the file monitoring unit 82 determines whether the hash value based on the executable file of the auditor 60 acquired in the current system monitoring process matches the auditor hash value HvA stored in the secure storage TS.

[0073] If the file monitoring unit 82 determines that the currently calculated hash values ​​for the logger 50, the EDR 70, and the auditor 60 match the monitoring hash values ​​HvL, HvE, and HvA, it determines that the executable files have not been tampered with. On the other hand, if it determines that at least one of the currently calculated hash values ​​does not match the hash values ​​HvL, HvE, and HvA, it determines that the executable files may have been tampered with. In this case, an error notification is sent to the user U, and the system monitoring process is terminated. Alternatively, the in-vehicle ECU 100 may be rebooted to transition to secure boot.

[0074] In this way, the file monitoring unit 81 operating in the secure world SW periodically monitors the executable files of the logger 50, EDR 70, and auditor 60, so that even if the logger 50, EDR 70, and auditor 60 are operating in the normal world NW, the correct operation of these is guaranteed by the file monitoring unit 81 operating in the secure world SW.

[0075] However, with regular monitoring, for example, if the executable file of EDR70, which plays a key role in associating and storing the protected data TD with the blockchain BC at the time when it is desired to protect it, is tampered with and becomes an unauthorized executable file, there is a possibility that the unauthorized EDR70 may request blocking of unintended data.

[0076] Therefore, the in-vehicle ECU 100 of this embodiment executes a process to securely generate a block based on the data to be protected at the timing to be protected, through cooperation of the EDR 70, the logger 50, and the observer 80, as described below in FIG. 3.

[0077] 3 is a flowchart showing the flow of a process for securely generating a block based on data to be protected at a timing to be protected, through cooperation between the EDR 70, the logger 50, and the observer 80. As described above, the EDR hash value HvE based on the executable file of the normal EDR 70 is stored in advance in the secure storage TS.

[0078] First, in step S200, the storage processing unit 72 calculates a target data hash value HvT of the protection target data TD acquired by the target data acquisition unit 71, and transmits the target data hash value HvT to the secure world SW to be stored in the secure storage TS of the secure world SW. At this time, the storage processing unit 72 also transmits a hash value based on the executable file of the EDR 70 to the secure world SW along with the target data hash value HvT.

[0079] Next, in step S201, the file monitoring unit 82 receives the target data hash value HvT and a hash value based on the executable file of the EDR 70 from the EDR 70.

[0080] In the next step S202, the file monitoring unit 82 determines whether the executable file of the EDR 70 received in step S201 has been tampered with, depending on whether an EDR hash value HvE (hereinafter sometimes referred to as the "first file hash value") stored in advance in the secure storage TS matches a hash value (hereinafter sometimes referred to as the "second file hash value") based on the executable file of the EDR 70 received in step S201. If the determination is affirmative (YES), the flow proceeds to step S203, and if the determination is negative (NO), the flow proceeds to step S213.

[0081] In step S203, since the EDR hash value HvE stored in advance in the secure storage TS matches the hash value based on the executable file of the EDR 70 received in step S201, the instruction to store the target data hash value HvT in the secure storage TS by the storage processing unit 72 in step S200 is executed, and the target data hash value HvT is stored in the secure storage TS. As a result, if the executable file of the EDR 70 (particularly the executable file related to the block generation request unit 73) is normal and has no abnormalities such as tampering or deletion, that is, if the EDR hash value HvE (first file hash value) matches the second file hash value, the target data hash value HvT is stored in the secure storage TS.

[0082] In step S204, the storage of the target data hash value HvT in the secure storage TS triggers the block generation request unit 73 to request the block generation unit 52 to generate a block based on the protection target data TD. At this time, the block generation request unit 73 may pass the protection target data TD directly to the block generation unit 52, or the block generation request unit 73 may pass the file path of the protection target data TD specified in the normal storage US to the block generation unit 52. In this way, after the target data hash value HvT is first stored in the secure storage TS in step S203, a request is made to generate a block for the protection target data TD. This gives priority to storing the target data hash value HvT in the secure storage TS, making it easier to ensure the accuracy of the target data hash value HvT stored in the secure storage TS.

[0083] In step S205, the block generation unit 52 calculates a hash value of the protection target data TD.

[0084] In step S206, the block generation unit 52 transmits the hash value of the protection target data TD calculated in step S205 to the secure world SW.

[0085] In step S207, the hash value determination unit 81 receives the hash value of the protection target data TD transmitted from the block generation unit 52 in step S206.

[0086] In step S208, the hash value determination unit 81 acquires the target data hash value HvT stored in the secure storage TS in step S203.

[0087] In step S209, the hash value determination unit 81 determines whether the hash value of the protected data TD received from the block generation unit 52 in step S207 matches the target data hash value HvT obtained in step S208, and returns the determination result to the block generation unit 52.

[0088] In step S210, the block generation unit 52 checks the judgment result returned in step S209, and if the judgment result indicates a match between the two (YES), the flow proceeds to step S211, and if the judgment result indicates a mismatch between the two (NO), the flow proceeds to step S212.

[0089] In step S211, the block generation unit 52 generates a block based on the protection target data TD.

[0090] In step S212, the block generation unit 52 does not generate a block based on the protection target data TD, and discards the protection target data TD.

[0091] In step S213, which is performed if the determination in step S202 is negative, since the hash values ​​of the executable files do not match, it is determined that an unintended data blocking request has been made due to tampering with the executable file of EDR 70, and the in-vehicle ECU 100 is rebooted, the process transitions to secure boot, and the target data hash value HvT is discarded. As a result, the hash value of an unauthorized executable file of EDR 70 cannot be stored in secure storage TS, so that the block generator 52 will not generate a block even if it receives an unauthorized blocking request.

[0092] In this way, the data storage device of this embodiment is used in a mobile body A and uses a blockchain to store the protected data TD acquired by the mobile body A. The data storage device of this embodiment includes a storage processing unit 72 that stores a first hash value of the protected data TD in a secure storage TS of a secure world SW to which access from the normal world NW is restricted, a block generation request unit 73 that requests the generation of a block based on the protected data TD to be linked to a blockchain BC, and a block generation unit 52 that calculates a second hash value of the protected data TD in response to a request from the block generation request unit 73 and generates a block if the first hash value and the second hash value match.

[0093] With this configuration, in the data storage device of this embodiment, a block is generated based on the protection target data TD when the first hash value of the protection target data TD stored in the secure storage TS matches the second hash value of the protection target data TD calculated in response to a request from the block generation request unit 73. Therefore, a block can be securely generated in response to a block generation request from the block generation unit 52.

[0094] (Other Embodiments) Although the embodiments of the present disclosure have been described above, the present disclosure should not be construed as being limited to the above-described embodiments, and can be applied to various embodiments and combinations within the scope that does not deviate from the gist of the present disclosure.

[0095] In the above example, the protection target data TD acquired by the EDR 70 and the data acquired by the logger 50 are stored using a common blockchain BC. However, in Modification 1 of the above embodiment, the blockchain used to store the protection target data TD acquired by the EDR 70 is separate from the blockchain used to store the protection target data TD acquired by the logger 50. In this case, the EDR 70 may also be provided with functional units corresponding to the block generation unit 52, the data storage unit 53, and the hash value storage unit 54.

[0096] In the above embodiment, the auditor 60 operates in the normal world NW. However, in the second modification of the above embodiment, the auditor 60 operates in the secure world SW. As described above, if the secure world SW has sufficient computational resources, the auditor 60 may be placed in the secure world SW as in the second modification. In this case, the function of the observer 70 that monitors the auditor 60 can be omitted.

[0097] In the third modification of the above embodiment, the function of transmitting backup data to the backup server BS is omitted. The in-vehicle ECU 100 of this type can also be installed in a vehicle A that is not a connected car.

[0098] In the fourth modification of the above embodiment, the timing of calculating the hash value of the log data LD in the logger processing is different. Specifically, in the logger processing of the fourth modification, when it is determined that the log data LD has reached a designated number or a designated capacity, each hash value of all the log data LD to be incorporated into one block is calculated. As described above, a flow may be adopted in which, once all the log data LD is collected, the hashes of that data are calculated all at once.

[0099] In the above embodiment, a form in which a normal world NW and a secure world SW are defined for the in-vehicle ECU 100 has been described, but the present invention is not limited to this, and a secure world SW does not have to be defined for the in-vehicle ECU 100. In this form, the block hash value HvB, block number NoB, monitoring hash values ​​HvL, HvE, HvA, target data hash value HvT, etc. are stored in the normal storage US of the normal world NW, but this data may be stored in a storage similar to the secure storage TS, such as a storage that cannot be directly accessed from the normal world NW or a storage to which access is restricted.

[0100] The data that can be stored by the data storage device is not limited to text data. Depending on the capacity of the normal storage US, it may be possible to store, for example, audio data, image data, video data, etc. Furthermore, the data stored in each block of the blockchain BC may also be changed as appropriate.

[0101] The hash function used in the in-vehicle ECU 100 of the above embodiment is a cryptographic hash function. A cryptographic hash function has the property that it never outputs the same hash value from different inputs, and that it is virtually impossible to guess the input from the output hash value. Instead of the above-mentioned SHA-256, which is one of SHA-2, the SHA-1, SHA-2, and SHA-3 algorithms may be used as appropriate according to the required output length (number of bits). Furthermore, an irreversible value that becomes a unique value of data or a program may be used instead of the hash value. Furthermore, an irreversible unique value calculated from data may be used instead of the hash value. An example of a unique value that can be used instead of a hash value is a discrete cosine transform (DCT).

[0102] The vehicle A equipped with the on-vehicle ECU 100 may be a private car that is privately owned by a specific owner and is intended for use by that owner, etc. When applied to a private car, the log data LD that indicates the user's driving history and is stored in a state protected from fraud becomes highly valuable to, for example, a service provider that sets insurance premiums according to driving conditions.

[0103] The vehicle equipped with the on-vehicle ECU 100 may be a rental car vehicle, a manned taxi vehicle, a ride-sharing vehicle, a freight vehicle, a bus, etc. Furthermore, the on-vehicle ECU 100 may be installed in a driverless vehicle used for a mobility service. As mobility services become more widespread in the future, the importance of the log data LD accumulated in the on-vehicle ECU 100 is expected to become even greater.

[0104] Furthermore, an ECU with a data storage function can be installed in moving objects other than vehicles, such as heavy machinery used at work sites, driving toys arranged in amusement facilities, railroad cars, trams, and aircraft.

[0105] In the above embodiment, each function provided by the in-vehicle ECU 100 can be provided by software and hardware that executes the software, software alone, hardware alone, or a combination of these. When such a function is provided by an electronic circuit as hardware, each function can also be provided by a digital circuit including a large number of logic circuits or an analog circuit.

[0106] Each processor in the above embodiments may include at least one arithmetic core such as a central processing unit (CPU) and a graphics processing unit (GPU).Furthermore, the processor may further include an IP core having a field-programmable gate array (FPGA) or other dedicated functions.

[0107] The form of the storage medium employed as the storage unit in the above embodiment and storing each program related to the data storage method of the present disclosure may be modified as appropriate. For example, the storage medium is not limited to a configuration mounted on a circuit board, but may be provided in the form of a memory card or the like, inserted into a slot, and electrically connected to a computer bus. Furthermore, the storage medium may be an optical disk or hard disk drive, from which the program is copied to the computer.

[0108] The controller and methods described herein may be implemented by a special-purpose computer comprising a processor programmed to perform one or more functions embodied in a computer program. Alternatively, the apparatus and methods described herein may be implemented by special-purpose hardware logic circuitry. Alternatively, the apparatus and methods described herein may be implemented by one or more special-purpose computers comprising a processor executing a computer program in combination with one or more hardware logic circuits. Furthermore, the computer program may be stored as instructions executed by a computer on a computer-readable non-transitory storage medium.

[0109] Furthermore, the processing flow described in the above embodiment is also an example, and unnecessary steps may be deleted, new steps may be added, or the processing order may be rearranged within the scope of the present disclosure.

[0110] The present invention may be provided in the following aspects: (Aspect 1) A data storage device (100) is used in a mobile body (A) and stores protected data (TD) acquired by the mobile body using a blockchain (BC), the data storage device comprising: a storage processing unit (72) that stores a first hash value of the protected data in a secure storage (TS) in a secure world (SW) where access from a normal world (NW) is restricted, a block generation request unit (73) that is linked to the blockchain and requests the generation of a block based on the protected data, and a block generation unit (52) that calculates a second hash value of the protected data in response to a request from the block generation request unit, and generates the block if the first hash value and the second hash value match.

[0111] According to this aspect, if the first hash value of the protection target data stored in the secure storage matches the second hash value of the protection target data calculated in response to a request from the block generation request unit, a block is generated based on the protection target data. Therefore, a block can be securely generated in response to a block generation request from the block generation request unit.

[0112] (Aspect 2) The data storage device according to aspect 1, wherein the storage processing unit causes the secure storage to store the first hash value of the protection target data at a timing when the protection target data is generated.

[0113] According to this aspect, the storage processing unit immediately stores the first hash value of the protection target data in the secure storage when the protection target data is generated, which makes it easier to ensure the accuracy of the hash value of the protection target data stored in the secure storage.

[0114] (Aspect 3) The data storage device according to aspect 1 or 2, wherein the block generation request unit requests generation of the block in response to the storage processing unit causing the first hash value to be stored in the secure storage.

[0115] According to this aspect, first, the first hash value of the protection target data is stored in the secure storage, and then a request is made to generate blocks for the protection target data. This makes it easier to ensure the accuracy of the hash value of the protection target data stored in the secure storage.

[0116] (Aspect 4) The data storage device according to any one of aspects 1 to 3, wherein the block generation unit does not generate the block if the first hash value and the second hash value do not match.

[0117] According to this aspect, if the first hash value and the second hash value do not match, no block is generated, so data that has been tampered with, lost, or otherwise abnormal is not blocked, and only correct data can be blocked.

[0118] (Aspect 5) The data storage device according to any one of Aspects 1 to 4, further comprising a hash value determination unit (81) that determines whether the first hash value and the second hash value match and returns the determination result to the block generation unit.

[0119] According to this aspect, the hash value comparison by the hash value determination unit is performed within the data storage device, making it possible to generate secure blocks quickly and easily.

[0120] (Aspect 6) The data storage device according to aspect 5, wherein the hash value determination unit operates in the secure world.

[0121] According to this aspect, there is no risk of tampering with the executable file of the hash value judgment unit, so the accuracy of the judgment result of the hash value judgment unit can be ensured, and blocks can be generated securely.

[0122] (Aspect 7) The data storage device according to any one of Aspects 1 to 6, further comprising a file monitoring unit (82) that operates in the secure world and determines whether an executable file associated with at least one of the block generation request unit, the storage processing unit, and the block generation unit has been tampered with.

[0123] According to this aspect, even if the block generation request unit, storage processing unit, and block generation unit are each operated in the normal world, their correct operation is guaranteed by the file monitoring unit operating in the secure world. Also, because each executable file, which tends to be large, can be stored in normal storage in the normal world, it is possible to accurately verify whether each executable file has been tampered with while reducing the amount of data stored in the secure storage.

[0124] (Aspect 8) A data storage device according to aspect 7, wherein the secure storage stores a hash value based on a normal executable file associated with the block generation request unit as a first file hash value in advance, the file monitoring unit determines whether the executable file has been tampered with based on whether the first file hash value matches a second file hash value based on the executable file when the secure storage stores the first hash value of the protected data, and the storage processing unit stores the first hash value in the secure storage when the file monitoring unit determines that the first file hash value matches the second file hash value.

[0125] According to this aspect, if the executable file related to the block generation request unit has been tampered with or has been deleted, the first file hash value and the second file hash value will not match, and the first hash value of the protected data cannot be stored in the secure storage. Therefore, even if the block generation unit receives an invalid blocking request, no blocks will be generated.

[0126] (Aspect 9) The data storage device according to Aspect 8, wherein the storage processing unit reboots the data storage device and transitions to secure boot when the file monitoring unit determines that the first file hash value and the second file hash value do not match.

[0127] According to this aspect, if the first file hash value and the second file hash value do not match, the data storage device transitions to secure boot. Therefore, even if the block generator receives an invalid blocking request, no blocks are generated.

[0128] (Aspect 10) The data storage device according to any one of aspects 1 to 9, wherein the storage processing unit, the block generation request unit, and the block generation unit operate in the normal world.

[0129] According to this aspect, it is possible to reduce consumption of resources in the secure world.

[0130] (Aspect 11) The data storage device according to any one of Aspects 1 to 10, further comprising a target data acquisition unit (71) that acquires the protection target data, wherein the target data acquisition unit acquires the protection target data when a predetermined operation occurs on a mobile body equipped with the data storage device.

[0131] According to this aspect, when a predetermined action occurs in a mobile object equipped with a data storage device, the protected data can be acquired. Therefore, the data storage device can store the acquired protected data using a blockchain at a desired timing when the predetermined action occurs.

[0132] (Aspect 12) A mobile object (A) comprising the data storage device according to any one of aspects 1 to 11.

[0133] (Aspect 13) A data storage program used in a mobile body (A) that stores protected data acquired by the mobile body using a blockchain, the data storage program causing a computer to function as: a storage processing unit that stores a first hash value of the protected data in secure storage in a secure world where access from the normal world is restricted; a block generation request unit that requests the generation of a block based on the protected data, linked to the blockchain; and a block generation unit that calculates a second hash value of the protected data upon request from the block generation request unit, and generates the block if the first hash value and the second hash value match.

[0134] Although the present disclosure has been described with reference to the embodiments, it is understood that the present disclosure is not limited to the embodiments or structures. The present disclosure also encompasses various modifications and equivalent modifications. In addition, various combinations and forms, including only one element, more than one element, or less than one element, are also within the scope and spirit of the present disclosure.

Claims

1. A data storage device (100) used in a mobile body (A) and storing protected data (TD) acquired by the mobile body using a blockchain (BC), comprising: a storage processing unit (72) that stores a first hash value of the protected data in a secure storage (TS) in a secure world (SW) where access from a normal world (NW) is restricted; a block generation request unit (73) that requests the generation of a block based on the protected data and is linked to the blockchain; and a block generation unit (52) that calculates a second hash value of the protected data upon request from the block generation request unit, and generates the block if the first hash value and the second hash value match.

2. The data storage device according to claim 1, wherein the storage processing unit causes the secure storage to store the first hash value of the data to be protected when the data to be protected is generated.

3. The data storage device according to claim 1, wherein the block generation request unit requests generation of the block in response to the storage processing unit storing the first hash value in the secure storage.

4. The data storage device according to claim 1, wherein the block generation unit does not generate the block if the first hash value and the second hash value do not match.

5. The data storage device according to claim 1, further comprising a hash value determination unit (81) that determines whether the first hash value and the second hash value match and returns the determination result to the block generation unit.

6. The data storage device according to claim 5, wherein the hash value determination unit operates in the secure world.

7. The data storage device of claim 1, further comprising a file monitoring unit (82) that operates in the secure world and determines whether or not an executable file associated with at least one of the block generation request unit, the storage processing unit, and the block generation unit has been tampered with.

8. A data storage device as described in claim 7, wherein the secure storage pre-stores a hash value based on a normal executable file associated with the block generation request unit as a first file hash value, the file monitoring unit determines whether the executable file has been tampered with depending on whether the first file hash value matches a second file hash value based on the executable file when the secure storage is caused to store the first hash value of the protected data, and the storage processing unit causes the secure storage to store the first hash value when the file monitoring unit determines that the first file hash value matches the second file hash value.

9. The data storage device of claim 8, wherein the storage processing unit reboots the data storage device and transitions to secure boot when the file monitoring unit determines that the first file hash value and the second file hash value do not match.

10. The data storage device of claim 1, wherein the storage processing unit, the block generation request unit, and the block generation unit operate in the normal world.

11. A data storage device as described in claim 1, further comprising a target data acquisition unit (71) for acquiring the protected data, wherein the target data acquisition unit acquires the protected data when a specified operation occurs on the mobile body equipped with the data storage device.

12. A mobile object (A) equipped with a data storage device according to any one of claims 1 to 11.

13. A data storage program used in a mobile body (A) that stores protected data acquired by the mobile body using a blockchain, the data storage program causing a computer to function as: a storage processing unit that stores a first hash value of the protected data in secure storage in a secure world where access from the normal world is restricted; a block generation request unit that requests the generation of a block based on the protected data and is linked to the blockchain; and a block generation unit that calculates a second hash value of the protected data upon request from the block generation request unit and generates the block if the first hash value and the second hash value match.

Images