Data storage device, mobile object, and data storage program

Abstract

To provide a data storage device, a mobile object and a data storage program capable of securely generating a block based on data desired to be protected at timing desired to be protected.SOLUTION: A data storage device 100 stores protection object data TD, by using a block chain BC. The data storage device comprises: a storage processing unit 72 which stores a first hash value of protection object data TD, in a secure storage TS of a secure world SW in which access from a normal world NW is restricted; a block generation request unit 73 which is connected to the block chain BC, and requires generation of a block based on the protection object data TD; and a block generation unit 52 which calculates a second hash value of the protection object data TD according to the request from the block generation request unit 73, and generates the block when the first hash value coincides with the second hash value.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a data storage device, a moving body, and a data storage program.

Background Art

[0002] In recent years, the importance of data acquired by moving bodies such as vehicles has been increasing. For this reason, there is a demand for a device that can store data acquired by a moving body such as a vehicle while ensuring credibility.

[0003] Patent Document 1 describes a data storage device in which in-vehicle ECU stores acquired data 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 log data of a preset specified number or specified capacity.

Prior Art Documents

Patent Documents

[0004]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] As described above, in the data storage device described in Patent Document 1, since the timing of generating a block is when the log data reaches a preset specified number or specified capacity, it is not possible to generate a block at a timing when it is desired to generate a block immediately, such as at the time of an accident.

[0006] In view of the above background, an object of the present invention is to provide a data storage device, a moving body, and a data storage program capable of securely generating a block based on data to be protected at a timing when the block is desired to be protected.

Means for Solving the Problems

[0007] The present invention employs the following technical means to solve the above problems. The claims and the reference numerals in parentheses described in this section are an example showing the correspondence with the specific means described in the embodiments to be described later as one aspect, and do not limit the technical scope of the present invention.

[0008] A data storage device (100) according to one aspect of the present invention is used in a moving body (A), and is a data storage device that stores protected target data (TD) acquired by the moving body using a blockchain (BC). The data storage device includes a storage processing unit (72) that stores a first hash value of the protected target 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 generation of a block based on the protected target data and is connected to the blockchain, and a block generation unit (52) that calculates a second hash value of the protected target data in response to a request from the block generation request unit and generates the block when the first hash value and the second hash value match.

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

[0010] A moving body (A) according to one aspect of the present invention includes the above data storage device.

[0011] A data storage program according to an aspect of the present invention is a data storage program used in a mobile body (A) for storing protected data acquired by the mobile body using a blockchain. The program causes a computer to function as a storage processing unit that stores a first hash value of the protected data in a secure storage in a secure world where access from the normal world is restricted, a block generation request unit that requests generation of a block based on the protected data, which is linked to the blockchain, and a block generation unit 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 when the first hash value and the second hash value match.

Advantages of the Invention

[0012] According to the present invention, it is possible to provide a data storage device, a mobile body, and a data storage program that can securely generate a block based on data to be protected at a timing when the block is to be protected.

Brief Description of the Drawings

[0013]

Figure 1

Figure 2

Figure 3

Embodiments for Carrying Out the Invention

[0014] Hereinafter, embodiments of the present invention will be described with reference to the drawings. Note that the embodiments described below are examples of implementing the present invention and do not limit the present invention to the specific configurations described below. In implementing the present invention, specific configurations according to the embodiments may be appropriately adopted.

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

[0016] The DCM 40 is a communication module mounted on the vehicle A. The DCM 40 transmits and receives radio waves to and from a base station around the vehicle A by wireless communication conforming to communication standards such as LTE (Long Term Evolution) and 5G. The DCM 40 enables cooperation (Cloud to Car) between the cloud CLD and in-vehicle devices. By mounting the DCM 40, the vehicle A becomes a connected car that can be connected to the Internet. The DCM 40 transmits a backup of the data stored in the in-vehicle ECU 100 to a backup server BS installed on the cloud CLD. In addition, the DCM 40 receives 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, road-to-vehicle communication, pedestrian-to-vehicle communication, etc. The V2X communication device 30 can communicate bidirectionally with these communication configurations when in-vehicle devices mounted on other vehicles, roadside devices installed on the road, mobile terminals possessed by pedestrians, etc. are within the communication range. The V2X communication device 30 can transmit communication data acquired through communication to the in-vehicle ECU 100 through, for example, a communication bus of the in-vehicle communication network.

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

[0019] The in-vehicle ECU 100 is an in-vehicle computer that has a function as a data storage device that acquires data generated in the vehicle A and stores the acquired data as log data LD in a state where it is difficult to falsify. The in-vehicle ECU 100 is mainly composed of a control circuit including a processor 11, a RAM (Random Access Memory) 12, a storage unit 13, and an input / output interface 14 and the like.

[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 is configured to include 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 the log data LD generated in the vehicle A.

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

[0022] The normal world NW is a normal area for executing an operating system and applications. In the normal world NW, a normal storage US is provided as a storage area (Untrusted Storage) for data storage.

[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 processing that requires security are executed. Access from the normal world NW to the secure world SW is restricted by the function of the processor 11. Therefore, from the normal world NW, the existence of the secure world SW cannot be recognized, and the security of the processing executed in the secure world SW and the information stored in the secure world SW is ensured. In the secure world SW, a secure storage TS is provided as a storage area (Trusted Storage) for data storage. The capacity of the secure storage TS may be less than the capacity of the normal storage US.

[0024] The in-vehicle ECU 100 of the present embodiment stores the acquired data using the blockchain BC. Further, the in-vehicle ECU 100 of the present embodiment executes a logger process for storing log data LD, an EDR process for securely storing protected data TD (hereinafter sometimes referred to as "data to be protected") in association with the blockchain BC at a timing when protection is desired, a data providing process for providing the log data LD accumulated by the logger process and / or the EDR process to the outside, and a system monitoring process for monitoring the state of the system. As functional units for executing the above respective 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 saves various data generated in vehicle A in association with the blockchain BC by executing logger processing. 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, the communication bus of the in-vehicle communication network. The data acquisition unit 51 can acquire various data generated in 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 sensor 20 and the V2X communication device 30, selectively acquires it as acquisition 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 converts the log data LD into a hash chain-like data structure using the hash function. The block generation unit 52 creates one block based on the preset specified number or specified capacity of log data LD. The block generation unit 52 generates a blockchain BC formed by linearly connecting a number of blocks by including the hash value obtained by inputting the data of one block into the hash function in the next block.

[0028] The block generation unit 52 calculates the hash value to be stored as main body data in each block based on the specified number or specified capacity of log data LD acquired by the data acquisition unit 51. The block generation unit 52 may calculate the hash value for each of a number of log data LD individually, or may calculate the Merkle root of a number of log data LD. In this embodiment, although the hash value is stored as the main body data in each block, 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 at the file path specified within 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 the association information Lin that associates 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 the block number NoB stored in the secure storage TS by executing a predetermined instruction (such as a secure monitor call etc.) that enables access to the secure world SW. The block hash value HvB is the 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 an output by an arithmetic process of inputting all the data of the final block LB into a hash function.

[0031] The block number NoB is a unique value assigned to the final block LB, and when the initial block is "0", it is a value indicating which block the current final block LB is in the blockchain BC. The block number NoB is also a value indicating the number of blocks currently connected in the blockchain BC. The hash value storage unit 54 updates the block hash value HvB and the block number NoB in the secure storage TS every time a new block AB is generated by the block generation unit 52 and its hash value is calculated.

[0032] The details of the logger process implemented by the above logger 50 will be described below with reference to FIG. 1 based on the flowchart shown in FIG. 2. The logger process is started based on the start of power supply to the in-vehicle ECU 100 and continues to be executed until the power supply ends.

[0033] In step S101, the block generation unit 52 determines whether the initial block of the blockchain BC has already been generated in the normal storage US. If it is determined in step S101 that there is an initial block in the normal storage US, the flow proceeds to step S105. On the other hand, if it is determined in step S101 that there is no initial block 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 arbitrary data and generates an initial block that stores 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 the 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. In addition, in step S104, the hash value storage unit 54 records "0" as the initial value at the address of the secure storage TS that stores the block number NoB.

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

[0038] In step S106, the data acquisition unit 51 determines whether the acquisition data to be stored has been acquired. If the data to be stored is not acquired, the process waits for the occurrence of the corresponding data by repeating the determination in step S106. Then, at the timing when the data acquisition unit 51 acquires the data to be stored 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 the hash value of the log data LD stored in step S107. By sequentially executing the acquisition of the log data LD and the calculation of the hash value in steps S106 and S108, the processing load is dispersed 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 the specified number or specified capacity. If it is determined in step S109 by the block generation unit 52 that the log data LD has not reached the specified number or specified capacity, the flow returns to step S106 and the data acquisition unit 51 continues to collect the log data LD. On the other hand, if it is determined in step S109 by the block generation unit 52 that the log data LD has reached the specified number or specified capacity, the flow proceeds to step S110. Note that in step S109, the elapsed time since the generation of the previous new block AB may be counted, and the flow may be advanced to step S110 based on the elapse of a predetermined elapsed time (timeout).

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

[0043] In step S111, the data storage unit 53 generates association information Lin and stores the association information Lin in the normal storage US. The association information Lin is information that associates the new block AB generated in step S110 with the file path that defines the storage destination of the log data LD including the hash value 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. In addition, 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 the specified number or specified capacity, or when a predetermined elapsed time has passed since the generation of the previous 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, in the storage of the log data LD associated with the blockchain BC by the logger 50, the timing of generating the new block AB is entrusted to the block generation unit 52. For this reason, in the logger 50, the log data LD cannot be blocked at the timing when it is desired to generate a block immediately, such as during an accident.

[0047] Therefore, the in-vehicle ECU 100 of the present embodiment further includes an EDR 70 as a functional unit for blocking log data LD at a timing when it is desired to generate a block immediately, such as during an accident. The EDR 70 is a functional unit that, by executing EDR processing in cooperation with the logger 50 and an observer 80 described later, stores the protected target data TD generated in the vehicle A in association with the blockchain BC at a timing when it is desired to protect it. The EDR 70 is, for example, a drive recorder and can record data related to an accident when an accident occurs in the vehicle A. The EDR 70 can record data from a predetermined time before the time when an accident occurs in the vehicle A to a predetermined time after the time when an accident occurs in the vehicle A. Also, for example, not limited to the case where an accident occurs in the vehicle A, the EDR 70 may record vehicle information including the vehicle speed before and after in a time-series data when there is a collision of the vehicle A accompanied by the deployment of an airbag or the like or a state close to a collision. 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, for example, to a communication bus of the in-vehicle communication network. The target data acquisition unit 71 can acquire the protected target data TD to be protected from various data generated in the vehicle A, such as communication data and detection data, through the communication bus. The target data acquisition unit 71 acquires the protected target data TD from the data sequentially output to the communication bus by the in-vehicle sensor 20 and the V2X communication device 30 and stores it in the normal storage US as log data LD. The target data acquisition unit 71 acquires the protected target data TD when a predetermined operation occurs in the vehicle A, for example, when an accident occurs in the vehicle A, when the vehicle A performs dangerous driving, or when there is another vehicle performing dangerous driving such as weaving or interrupting around the vehicle A. Thereby, the acquired protected target data TD can be acquired at a desired timing, which is the timing when a predetermined operation occurs in the vehicle A, and stored using the blockchain.

[0049] When the speed of vehicle A detected from the output of a speed sensor, for example, is equal to or higher than a predetermined level, the target data acquisition unit 71 may determine that the vehicle is in an abnormal driving state of excessive speeding, and acquire the protected target data TD from a point in time a predetermined time before the time when the speed of vehicle A becomes equal to or higher than the predetermined speed to a point in time a predetermined time after the time when the speed of vehicle A becomes equal to or higher than the predetermined speed.

[0050] Alternatively, the target data acquisition unit 71 may detect the driver's state and driving operations from the outputs of, for example, an in-vehicle camera, a pedal sensor, or a steering sensor, determine that the driver's state and driving operations are abnormal in a predetermined case, and acquire the protected target data TD.

[0051] Alternatively, when the vibration level of vehicle A detected from the output of an inertial sensor is equal to or higher than a predetermined vibration level, or when the direction of vehicle A detected from the output of an inertial sensor changes suddenly, the target data acquisition unit 71 may determine that the vehicle is in an abnormal driving state of running wild or spinning, and acquire the protected target data TD.

[0052] Alternatively, the target data acquisition unit 71 may detect other vehicles performing dangerous driving around vehicle A from the outputs of, for example, an out-of-vehicle camera, a radar, or a lidar, and acquire the protected target data TD.

[0053] The save processing unit 72 stores the protected data TD acquired by the protected data acquisition unit 71 as log data LD in a specified file path in the normal storage US. The save processing unit 72 calculates the target data hash value HvT of the protected data TD acquired by the protected data acquisition unit 71 (hereinafter sometimes referred to as the "first hash value"), transmits the target data hash value HvT to the secure world SW where access from the normal world NW is restricted, and stores it in the secure storage TS in the secure world SW. The save processing unit 72 has a function of calculating a hash value using a hash function such as SH-256. The save processing unit 72 preferably stores the protected data TD as log data LD in the normal storage US by specifying a file path at the timing when the protected data TD is generated, and stores the target data hash value HvT of the protected data TD in the secure storage TS. The target data hash value HvT is the hash value of the protected data TD calculated at the timing when the protected data TD is generated. In this way, by immediately storing the target data hash value HvT in the secure storage TS at the timing when the protected data TD is generated, the possibility of abnormalities such as tampering or loss occurring in the protected data TD is reduced, and it becomes easier to ensure the correctness 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 is to be linked to the end of the blockchain BC. The block generation unit 52 calculates the hash value of the protected data TD (hereinafter sometimes referred to as the "second hash value") to be stored as the main body data in the newly generated block based on the protected data TD acquired by the protected data acquisition unit 71 according to the request from the block generation request unit 73. When the hash value determination unit 82 described later determines that this second hash value matches the target data hash value HvT (the first hash value), the block generation unit 52 generates a block based on the protected data TD. 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 the correct protected data TD without abnormalities such as forgery or loss can be securely blocked. Although the hash value of the protected data TD is stored in each block, the protected data TD itself may be stored in each block. Then, the block generation unit 52 calculates the hash value of the new block AB based on the newly generated protected data TD.

[0055] The data storage unit 53 of the logger 50 stores the association information Lin that associates the block based on the protected data TD generated by the block generation unit 52 with the file path of the protected data TD included in the block in the normal storage US. Note that the process of storing this association 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 data TD to be protected 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 providing 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 backup and restoration of the log data LD. The auditor 60 includes a data providing unit 61 and a data verification unit 62 as functional units related to the data providing process.

[0058] The data providing unit 61 can communicate with a user interface UI outside the in-vehicle ECU 100, either wired or wirelessly. 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 operation for referring to the log data LD is input by the user U to the user interface UI. 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 the 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 refer to. The data providing unit 61 extracts the file path of the acquired reference request and provides the file path to the data verification unit 62. When there is no problem with the verification result by the data verification 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 requester of the reference request.

[0060] Upon receiving a reference request from the data providing unit 61 as a trigger, the data verification unit 62 verifies anomalies 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 associated with the file path specified in the reference request based on the association 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 integrity of the blockchain BC.

[0061] The data verification unit 62 determines whether there is an anomaly in the log data LD based on whether or not the hash value based on the recalculated final block LB matches the block hash value HvB stored in the secure storage TS. When the hash value of the recalculated final block LB matches the block hash value HvB, the data verification unit 62 determines that there is no anomaly such as tampering in the log data LD. On the other hand, when the hash value of the recalculated final block LB does not match the block hash value HvB, the data verification unit 62 determines that there may be an anomaly such as tampering in the log data LD.

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

[0063] The backup transmission unit 63 detects the generation of the 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 number of log data LD with hash values 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 the ID information of the in-vehicle ECU 100 and stores it in a large-capacity storage medium such as a hard disk drive.

[0064] In a situation where communication by the DCM 40 is impossible, the backup transmission unit 63 suspends the transmission of the log data LD to the backup server BS. In this case, at the timing when the DCM 40 returns to a communicable state, the backup transmission unit 63 resumes the transmission of the backup data that has not been transmitted.

[0065] The data restoration unit 64 detects the abnormality determination by the data verification unit 62. When an abnormality such as forgery 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 the backup data stored in the backup server BS. The data restoration unit 64 requests the backup server BS to transmit the backup data for a plurality of log data LD in which hash values are incorporated in each block after the specific block SB that is the verification target of 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. Incidentally, the data restoration unit 64 may acquire all the backup data from the backup server BS and perform a process of updating all the log data LD.

[0066] By operating in the secure world SW, the observer 80 is protected from forgery from outside the in-vehicle ECU 100 and from the normal world NW. The observer 80 is a functional unit that monitors the states of the logger 50, the EDR 70, and the 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 or not a first hash value (target data hash value HvT) matches a second hash value (a hash value that is stored as main body data in a block newly generated based on the protected target data TD acquired by the protected target data acquisition unit 71 in response to a request from the block generation request unit 73), and performs a process of returning the determination result to the block generation unit 52 of the logger 50. By operating the hash value determination unit 81 in the secure world SW, the risk of the execution file of the hash value determination unit 81 being forged is eliminated. For this reason, the correctness of the determination result of the determination performed by the hash value determination unit 81 is ensured, and blocks can be generated securely. Also, by performing the comparison determination of the hash value of the protected target data TD in the data storage device, blockification can be performed quickly and simply in a secure manner.

[0068] The file monitoring unit 82 operates in the secure world SW and starts the system monitoring process at a predefined cycle, for example, for periodic monitoring. By operating the file monitoring unit 82 in the secure world SW, the risk of the execution file of the file monitoring unit 82 being tampered with is eliminated. The file monitoring unit 82 determines whether the execution files of the logger 50 required for the execution of the logger process, the execution files of the EDR 70 required for the execution of the EDR process, and the execution files of the auditor 60 required for the execution of the data provision process and the data maintenance process have been tampered with. As a result, even if the logger 50, the EDR 70, and the auditor 60 are each operating in the normal world NW, their correct operation is ensured by the file monitoring unit 82 operating in the secure world SW. In addition, since each execution file that is likely to be large in volume can be stored in the normal storage US in the normal world NW, while reducing the data volume stored in the secure storage TS, the presence or absence of tampering with each execution file can be accurately verified.

[0069] The file monitoring unit 82 acquires these execution files from the normal world NW. The execution file of the logger 50 is, in other words, the execution file related to each of the data acquisition unit 51, the block generation unit 52, the data storage unit 53, and the hash value storage unit 54. Similarly, the execution file of the EDR 70 is, in other words, the execution file related to each of the target data storage unit 71, the storage processing unit 72, and the block generation request unit 73. The execution file of the auditor 60 is, in other words, the execution file related to each of the data provision unit 61, the data verification unit 62, the backup transmission unit 63, and the data restoration unit 64. The file monitoring unit 82 comprehensively acquires the entire execution file. The execution file includes, for example, binary files. Furthermore, a compiler, a linker, a library, etc. may also be included in the execution file.

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

[0071] In the secure storage TS, hash values based on the initial execution files guaranteed to be unmodified are stored as monitoring hash values. Specifically, a logger hash value HvL based on the execution file of the normal logger 50, an EDR hash value HvE based on the execution file of the normal EDR 70, and an auditor hash value HvA based on the execution file of the normal auditor 60 are stored in the secure storage TS as monitoring hash values. The logger hash value HvL, the EDR hash value HvE, and the auditor hash value HvA are protected from being modified by access from the external and normal world NW by being stored in the secure storage TS.

[0072] The file monitoring unit 82 determines whether the hash value based on the execution file of the logger 50 obtained 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 execution file of the EDR 70 obtained 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 execution file of the auditor 60 obtained this time matches the auditor hash value HvA stored in the secure storage TS.

[0073] When the file monitoring unit 82 determines that each of the calculated hash values for the logger 50, the EDR 70, and the auditor 60 matches each of the monitoring hash values HvL, HvE, and HvA, the file monitoring unit 82 makes a normal determination indicating that each execution file has not been modified. On the other hand, when it is determined that at least one of the calculated hash values this time does not match each of the hash values HvL, HvE, and HvA, the file monitoring unit 82 makes an abnormal determination indicating that there is a possibility of modification in the execution file. In this case, an error notification is sent to the user U, and the series of system monitoring processes is terminated. Alternatively, the in-vehicle ECU 100 may be rebooted and the process may proceed to secure boot.

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

[0075] However, in the case of periodic monitoring, for example, when the execution file of the EDR 70, which plays a major role when storing in association with the blockchain BC at the timing when it is desired to protect the data to be protected TD, is tampered with and becomes an illegal execution file, there is a possibility that the illegal EDR 70 may request the blocking of data that is not intended.

[0076] Therefore, in the in-vehicle ECU 100 of the present embodiment, the process of securely generating a block based on the data to be protected at the timing when it is desired to protect the block by the cooperation of the EDR 70, logger 50, and observer 80 according to FIG. 3 described below is executed.

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

[0078] First, in step S200, the save processing unit 72 calculates the target data hash value HvT of the data to be protected TD acquired by the target data acquisition unit 71, and transmits it to the secure world SW in order to store the target data hash value HvT in the secure storage TS of the secure world SW. At this time, the save processing unit 72 also transmits the hash value based on the execution file of the EDR 70 to the secure world SW together with the target data hash value HvT.

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

[0080] In the next step S202, the file monitoring unit 82 determines whether there is any forgery of the execution file of the EDR 70 received in step S201 according to whether the EDR hash value HvE (hereinafter sometimes referred to as the "first file hash value") pre-stored in the secure storage TS matches the hash value based on the execution file of the EDR 70 received in step S201 (hereinafter sometimes referred to as the "second file hash value"). If the determination is affirmative (YES), the flow proceeds to step S203; if the determination is negative (NO), the flow proceeds to step S213.

[0081] In step S203, since the EDR hash value HvE pre-stored in the secure storage TS matches the hash value based on the execution file of the EDR 70 received in step S201, the instruction from the storage processing unit 72 in step S200 to store the target data hash value HvT in the secure storage TS is executed, and the target data hash value HvT is stored in the secure storage TS. Thus, when the execution file of the EDR 70 (especially the execution file related to the block generation request unit 73) is normal without any abnormalities such as forgery or loss, that is, when the EDR hash value HvE (the first file hash value) and the second file hash value match, the target data hash value HvT is stored in the secure storage TS.

[0082] In step S204, triggered by the fact that the target data hash value HvT has been stored in the secure storage TS, the block generation request unit 73 requests the block generation unit 52 to generate a block based on the data to be protected TD. At this time, the block generation request unit 73 may directly pass the data to be protected TD to the block generation unit 52, or the block generation request unit 73 may pass the file path specified within the normal storage US of the data to be protected TD to the block generation unit 52. In this way, first, after the target data hash value HvT is stored in the secure storage TS in step S203, a block generation request for the data to be protected TD is made. Thereby, by giving priority to storing the target data hash value HvT in the secure storage TS first, the correctness of the target data hash value HvT stored in the secure storage TS is easily ensured.

[0083] In step S205, the block generation unit 52 calculates the hash value of the data to be protected TD.

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

[0085] In step S207, the hash value determination unit 81 receives the hash value of the data to be protected TD transmitted from the block generation unit 52 in step 206.

[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 203.

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

[0088] In step S210, the block generation unit 52 checks the determination result returned in step S209. If the determination result indicates a match between the two (YES), the flow proceeds to step S211. If the determination 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 data TD to be protected.

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

[0091] In step S213, which is the step to which the process proceeds when a negative determination is made in step S202, since the hash values of the executable files do not match, it is assumed that there is a request to block unintended data due to forgery of the executable file of the EDR 70. The in-vehicle ECU 100 is rebooted, the process proceeds to secure boot, and the target data hash value HvT is discarded. As a result, since an illegal executable file of the EDR 70 cannot store its hash value in the secure storage TS, the block generation unit 52 will not generate a block even if it receives an illegal block generation request.

[0092] As described above, the data storage device according to the present embodiment is used in the moving body A and stores the data TD to be protected acquired in the moving body A using a blockchain. The data storage device according to the present embodiment includes a storage processing unit 72 that stores the first hash value of the data TD to be protected in a secure storage TS in a secure world SW where access from the normal world NW is restricted, a block generation request unit 73 that requests generation of a block based on the data TD to be protected and is connected to the blockchain BC, and a block generation unit 52 that calculates the second hash value of the data TD to be protected in response to a request from the block generation request unit 73 and generates a block when the first hash value and the second hash value match.

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

[0094] (Other embodiments) As described above, the embodiments of the present disclosure have been described. However, the present disclosure is not construed as being limited to the above embodiments, and can be applied to various embodiments and combinations without departing from the gist of the present disclosure.

[0095] In the above embodiment, the protected data TD acquired by the EDR 70 and the data acquired by the logger 50 were stored using the common blockchain BC. However, in Modification 1 of the above embodiment, the blockchain used when storing the protected data TD acquired by the EDR 70 and the blockchain used when storing the protected data TD acquired by the logger 50 are separated. In this case, the EDR 70 may 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] The auditor 60 of the above embodiment operated in the normal world NW. However, in Modification 2 of the above embodiment, the auditor 60 operates in the secure world SW. As described above, if there is a surplus in the computing resources of the secure world SW, the auditor 60 may be arranged in the secure world SW as in Modification 2. In this case, the function of the observer 70 that monitors the auditor 60 can be omitted.

[0097] In Modification 3 of the above embodiment, the function of transmitting backup data to the backup server BS is omitted. The in-vehicle ECU 100 in such a form can also be mounted on a vehicle A that is not a connected car.

[0098] In Modification Example 4 of the above-described embodiment, the timing of calculating the hash value of the log data LD in the logger process is different. Specifically, in the logger process of Modification Example 4, when it is determined that the log data LD has reached the specified number or specified capacity, the hash value of each of all the log data LD incorporated into one block is calculated. As described above, a flow may be adopted in which the hashes of all the log data LD are calculated at once after all the log data LD are gathered.

[0099] In the above-described embodiment, the form in which the normal world NW and the secure world SW are defined for the in-vehicle ECU 100 has been described. However, the present invention is not limited to this, and the secure world SW may not be defined for the in-vehicle ECU 100. In the case of this form, the block hash value HvB, the block number NoB, the monitoring hash values HvL, HvE, HvA, the target data hash value HvT, etc. are stored in the normal storage US in the normal world NW. However, these 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 whose 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, for example, audio data, image data, video data, etc. may be stored. Further, 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-described embodiment is a cryptographic hash function. A cryptographic hash function has the property that it does not output the same hash value from different inputs and it is substantially impossible to infer the input from the output hash value. Instead of the above-described SHA-256 which is one of SHA-2, each algorithm of SHA-1, SHA-2, and SHA-3 may be appropriately used according to the required output length (number of bits). Also, an irreversible value that becomes a unique value of data or a program may be used instead of the hash value. Further, an irreversible unique value calculated from data may be used instead of the hash value. The unique value that substitutes for the hash value is, for example, a discrete cosine transform (DCT).

[0102] Vehicle A equipped with the in-vehicle ECU 100 may be a privately-owned car owned by a specific owner and assumed to be used by the owner or the like. According to the application to a privately-owned car, log data LD indicating the driving history of the user accumulated in a state protected from forgery has high value, for example, for a service provider that sets insurance premiums according to the driving situation.

[0103] Also, the vehicle equipped with the in-vehicle ECU 100 may be a rental car, a manned taxi vehicle, a ride-sharing vehicle, a cargo vehicle, a bus, or the like. Further, the in-vehicle ECU 100 may be mounted on a driverless vehicle used for mobility services. With the expansion of future mobility services, the importance of the log data LD accumulated in the in-vehicle ECU 100 is expected to become even greater.

[0104] Furthermore, an ECU having the function of a data storage device can also be mounted on a moving body different from a vehicle. For example, it is possible to mount an ECU having the function of a data storage device on a heavy machine operated at a work site, a driving amusement device arranged in an amusement facility, a railway vehicle, a tram, and an aircraft.

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

[0106] Each processor of the above-described embodiment may be configured to include at least one arithmetic core such as a CPU (Central Processing Unit) and a GPU (Graphics Processing Unit). Further, the processor may be configured to further include an FPGA (Field-Programmable Gate Array) and an IP core having other dedicated functions.

[0107] The form of the storage medium that is adopted as the storage unit of the above-described embodiment and stores each program related to the data storage method of the present disclosure may be appropriately changed. For example, the storage medium is not limited to a configuration provided on a circuit board, may be provided in the form of a memory card or the like, and may be inserted into a slot portion and electrically connected to a computer bus. Further, the storage medium may be an optical disk and a hard disk drive or the like that serve as a copy base of a program to a computer.

[0108] The control unit and its method described in the present disclosure may be realized by a dedicated computer configured to include a processor programmed to execute one or more functions embodied by a computer program. Alternatively, the device and its method described in the present disclosure may be realized by a dedicated hardware logic circuit. Or, the device and its method described in the present disclosure may be realized by one or more dedicated computers configured by a combination of a processor that executes a computer program and one or more hardware logic circuits. Further, the computer program may be stored in a computer-readable non-transitory tangible recording medium as instructions to be executed by a computer.

[0109] Also, the processing flow described in the above embodiment is merely an example, and unnecessary steps may be deleted, new steps may be added, or the processing order may be changed within the scope not departing from the gist of the present invention.

[0110] It may be provided in each of the aspects described below. (Aspect 1) A data storage device (100) used in a mobile body (A) for storing protection target data (TD) acquired by the mobile body using a blockchain (BC), a storage processing unit (72) for storing a first hash value of the protection target data in a secure storage (TS) of a secure world (SW) restricted from access from a normal world (NW); a block generation request unit (73) for requesting generation of a block based on the protection target data, which is connected to the blockchain; a block generation unit (52) for calculating a second hash value of the protection target data according to a request from the block generation request unit and generating the block when the first hash value and the second hash value match; A data storage device comprising:

[0111] According to this aspect, when 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 according to a request from the block generation request unit, a block based on the protection target data is generated. 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 stores the first hash value of the protection target data in the secure storage at the timing when the protection target data is generated.

[0113] According to this aspect, the storage processing unit immediately stores the first hash value in the secure storage at the timing when the data to be protected is generated. Therefore, it is easy to ensure the correctness of the hash value of the data to be protected stored in the secure storage.

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

[0115] According to this aspect, first, the first hash value of the data to be protected is stored in the secure storage, and then a block generation request for the data to be protected is made. Therefore, it is easy to ensure the correctness of the hash value of the data to be protected stored in the secure storage.

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

[0117] According to this aspect, when the first hash value and the second hash value do not match, the block is not generated. Therefore, data with abnormalities such as forgery or loss 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 includes 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 determination for comparing the hash values by the hash value determination unit is performed within the data storage device. Therefore, a secure block can be generated quickly and easily.

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

[0121] According to this aspect, the risk of the execution file of the hash value determination unit being tampered with is eliminated. Therefore, the correctness of the determination result of the hash value determination 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 there is any tampering with the execution file related to at least one of the block generation request unit, the storage processing unit, and the block generation unit.

[0123] According to this aspect, even if the block generation request unit, the storage processing unit, and the block generation unit are each operating in the normal world, their correct operations are ensured by the file monitoring unit operating in the secure world. In addition, since each execution file that is likely to be large in volume can be stored in the normal storage in the normal world, while reducing the data volume stored in the secure storage, it becomes possible to accurately verify whether there is any tampering with each execution file.

[0124] (Aspect 8) In the secure storage, a hash value based on a normal execution file related to the block generation request unit is pre-stored as a first file hash value. The file monitoring unit determines whether there is any tampering with the execution file according to whether the first file hash value matches a second file hash value based on the execution file when storing the first hash value of the protected data in the secure storage. 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 and the second file hash value match. The data storage device according to Aspect 7.

[0125] According to this aspect, when there is an abnormality such as forgery or loss in the execution file related to the block generation request unit, the first file hash value and the second file hash value do not match, and the first hash value of the data to be protected cannot be stored in the secure storage. Therefore, even if the block generation unit receives an illegal block generation request, no block will be generated.

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

[0127] According to this aspect, when the first file hash value and the second file hash value do not match, the data storage device shifts to secure boot. Therefore, even if the block generation unit receives an illegal block generation request, no block will be 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, consumption of resources in the secure world can be reduced.

[0130] (Aspect 11) Further comprising a target data acquisition unit (71) for acquiring the data to be protected, The data storage device according to any one of aspects 1 to 10, wherein the target data acquisition unit acquires the data to be protected when a predetermined operation occurs to the mobile body equipped with the data storage device.

[0131] According to this aspect, when a predetermined operation occurs to a mobile body equipped with a data storage device, 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 operation occurs.

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

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

Explanation of Reference Numerals

[0134] 100... data storage device, TD... protected data, BC... blockchain, NW... normal world, SW... secure world, US... normal storage, TS... secure storage, 72... storage processing unit, 73... block generation request unit, 52... block generation unit, 81... hash value determination unit, 82... file monitoring unit, 71... target data acquisition unit, A... mobile body

Claims

1. A data storage device (100) used in a mobile body (A) for 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) of a secure world (SW) where access from a normal world (NW) is restricted; A block generation request unit (73) that requests generation of a block based on the protected data, which is linked to the blockchain; 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 when the first hash value and the second hash value match; A data storage device comprising the above.

2. The data storage device according to claim 1, wherein the storage processing unit stores the first hash value of the protected data in the secure storage at the timing when the protected data 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 when 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 according to claim 1, further comprising a file monitoring unit (82) that operates in the secure world and determines whether there is any forgery of an executable file related to at least one of the block generation request unit, the storage processing unit, and the block generation unit. **Claim 8** In the secure storage, a hash value based on a normal executable file related to the block generation request unit is pre-stored as a first file hash value. The file monitoring unit determines whether there is any forgery of the executable file according to whether the first file hash value matches a second file hash value based on the executable file when the first hash value of the protected data is stored in the secure storage. The data storage device according to claim 7, wherein 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. **Claim 9** The data storage device according to claim 8, wherein when the file monitoring unit determines that the first file hash value does not match the second file hash value, the storage processing unit reboots the data storage device and migrates to secure boot. **Claim 10** The data storage device according to claim 1, wherein the storage processing unit, the block generation request unit, and the block generation unit operate in the normal world. **Claim 11** The data storage device according to claim 1, further comprising a target data acquisition unit (71) that acquires the protected data. The target data acquisition unit acquires the protected data when a predetermined operation occurs to the mobile body equipped with the data storage device. **Claim 12** A mobile body (A) comprising the data storage device according to any one of claims 1 to 11. **Claim 13** A data storage program that is used in a mobile body (A) and stores protected target data acquired by the mobile body using a blockchain, causing a computer to, a storage processing unit that stores a first hash value of the protected target data in a secure storage of a secure world where access from the normal world is restricted; a block generation request unit that requests generation of a block based on the protected target data, which is linked to the blockchain; a block generation unit that calculates a second hash value of the protected target data in response to a request from the block generation request unit and generates the block when the first hash value and the second hash value match; Thereby functioning, a data storage program.

Images