Data storage devices and non-transitory tangible computer-readable storage media

Abstract

A data storage device and a non-transitory tangible computer-readable storage medium are provided. The data storage device in a mobile body (A) defines a normal world (NW) and a secure world (SW), and uses a blockchain (BC) to store data acquired in the mobile body. The data storage device includes: a normal storage processing unit (53) that stores the acquired data in a storage area (US) of the normal world; a block generator (52) that generates a new block (AB), wherein the new block (AB) includes a hash value based on the last block (LB) last coupled to the blockchain and a hash value based on the acquired data; and a secure storage processing unit (54) that stores the hash value based on the new block as a block hash value (HvB) in a storage area (TS) of the secure world.

Description

Technical Field

[0001] The present disclosure relates to a data storage technology for storing acquired data acquired in a movable body. Background Art

[0002] Patent document 1 discloses a driving recorder comprising: a recording device for receiving and recording driving information about a vehicle; and a non-volatile recording device for recording the driving information recorded in the recording device into a recording medium (e.g., such as a flash memory) in a non-volatile manner when predetermined conditions are met.

[0003] In recent years, the importance of acquired data acquired in a movable body such as a vehicle has been increasing. However, in the drive recorder of Patent Document 1, access to the recording medium from the outside is not restricted. This leads to the possibility that data such as driving information stored therein is not safe and reliable.

[0004] Patent Document 1 JP-2007-141213-A Summary of the invention

[0005] An object of the present disclosure is to provide a data storage device and a data storage program capable of storing acquired data acquired in a mobile body while ensuring the reliability of the acquired data acquired in the mobile body.

[0006] According to one aspect of the present disclosure, a data storage device in a mobile body (A), the data storage device being used to define a regular world and a secure world whose access from the regular world (NW) is restricted and being used to store data acquired in the mobile body using a blockchain, the data storage device comprising: a regular storage processing unit configured to store the acquired data in a storage area of ​​the regular world; a block generator configured to generate a new block, the new block comprising a hash value based on the last block last coupled to the blockchain and a hash value based on the acquired data; a secure storage processing unit configured to store the hash value based on the new block as a block hash value in the storage area of ​​the secure world.

[0007] According to another aspect of the present disclosure, a data storage program in a mobile body, the data storage program is used to define a regular world and a secure world whose access from the regular world is restricted and is used to store data acquired in the mobile body using a blockchain, the data storage program causes at least one processor to execute instructions, the instructions including: storing the acquired data in a storage area in the regular world; generating a new block, the new block including a hash value based on the last block last coupled to the blockchain and a hash value based on the acquired data; and storing the hash value based on the new block as a block hash value in the storage area in the secure world.

[0008] In the aforementioned aspect, the hash value of the new block newly coupled to the blockchain is stored as a block hash value in a storage area in the secure world whose access from the regular world is restricted. This makes it possible to detect changes in the acquired data acquired in the mobile body, etc., by comparison using the block hash value protected in the secure world. This makes it possible to store the acquired data acquired in the mobile body while ensuring the reliability of the acquired data acquired in the mobile body. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The above and other objects, features and advantages of the present disclosure will become more apparent from the following detailed description made with reference to the accompanying drawings. In the accompanying drawings:

[0010] Figure 1 is a block diagram showing an electrical structure of an in-vehicle ECU and an in-vehicle structure related thereto according to a first embodiment of the present disclosure;

[0011] Figure 2 is a diagram showing details of a blockchain;

[0012] Figure 3 is a flowchart showing details of a recorder process performed by the recorder;

[0013] Figure 4 is a flow chart showing details of the data provision process performed by the auditor;

[0014] Figure 5 is a diagram showing an example of a data providing screen displayed on a user interface;

[0015] Figure 6 is a flowchart showing details of a system monitoring process performed by a viewer; and

[0016] Figure 7 is a block diagram showing an electrical structure of a vehicle-mounted ECU according to a second embodiment of the present disclosure. DETAILED DESCRIPTION

[0017] First embodiment

[0018] Figure 1The functions of the data storage device according to the first embodiment of the present disclosure are shown, wherein these functions are implemented in an on-vehicle ECU (electronic control unit) 100. The on-vehicle ECU 100 is one of a plurality of electronic control units incorporated in a vehicle A. For example, the on-vehicle ECU 100 may be a body system integrated ECU or an autonomous driving ECU for autonomous driving or high-level driving assistance. The on-vehicle ECU 100 may also be a dedicated ECU for storing acquired data. The on-vehicle ECU 100 is electrically connected directly or indirectly to the DCM 40, the V2X communication unit 30, a plurality of on-vehicle sensors 20, and the like.

[0019] The DCM (Data Communication Module) 40 is a communication module incorporated in the vehicle A. The DCM 40 transmits and receives radio waves to and from base stations around the vehicle A through wireless communication conforming to communication standards such as LTE (Long Term Evolution) and 5G.

[0020] The DCM 40 enables collaboration between the cloud CLD and the vehicle-mounted device (cloud to car). The vehicle A becomes a networked car that can be connected to the Internet due to the DCM 40 incorporated therein. The DCM 40 sends a backup of the data stored in the vehicle-mounted ECU 100 to a backup server (backup storage device or backup memory) BS installed in the cloud CLD. In addition, the DCM 40 receives backup data stored in the backup server BS.

[0021] The V2X (Vehicle to Everything) communication unit 30 is an on-vehicle communication device for realizing vehicle-to-vehicle communication, road-to-vehicle communication, pedestrian-to-vehicle communication, etc. When there is an on-vehicle unit incorporated in another vehicle, a roadside device installed on the road, a portable terminal carried by a pedestrian, etc. within the communication range, the V2X communication unit 30 can perform two-way communication with these communication structures. For example, the V2X communication unit 30 can provide the communication data acquired through the communication to the on-vehicle ECU 100 through a communication bus in the on-vehicle communication network, etc.

[0022] The on-board sensor 20 is a detection structure of various types incorporated in the vehicle A. The on-board sensor 20 includes a vehicle speed sensor and an inertial sensor (inertial measurement unit, IMU) for detecting the driving condition of the vehicle A. The on-board sensor 20 includes an in-vehicle camera, a pedal sensor, and a steering sensor for detecting the driver's condition and driving operation. The on-board sensor 20 includes an outside camera, a millimeter wave radar, and a laser radar used in driving assistance or automatic driving. For example, each of the on-board sensors 20 is capable of providing detection data to the on-board ECU 100 through a communication bus in a vehicle communication network, etc.

[0023] The vehicle-mounted ECU 100 is a vehicle-mounted computer adapted to acquire data generated (i.e. produced) in the vehicle A in a state where the acquired data is difficult to change and accumulate the acquired data as a recording data segment LD. The vehicle-mounted ECU 100 is mainly composed of a control circuit including a processor 11, a RAM 12, a storage unit 13, an input / output interface 14, and the like.

[0024] The processor 11 is hardware for operation processing, which is coupled to the RAM 12, and the processor 11 can execute various types of programs through a process for accessing the RAM 12. The storage section 13 includes a nonvolatile storage medium and stores various types of programs to be executed by the processor 11. The storage section 13 stores at least a data storage program related to accumulation, provision, and monitoring of the recorded data segments LD generated in the vehicle A.

[0025] The vehicle-mounted ECU 100 defines at least two different processing areas in the system, which are referred to as the normal world NW and the secure world SW. The normal world NW and the secure world SW can be physically separated from each other in hardware, or virtually separated from each other through the cooperation of hardware and software. The vehicle-mounted ECU 100 temporarily separates the resources required for executing applications in the normal world NW and the secure world SW by utilizing a function such as context switching.

[0026] The normal world NW is a normal area for executing an operating system and applications. The normal world NW is provided with a normal storage device US as a storage area (untrusted storage) for storing data.

[0027] The secure world SW is an area isolated from the normal world NW. In the secure world SW, secure operating systems and applications for processing that requires security are executed. Access to the secure world SW from the normal world NW is limited by the function of the processor 11. This makes it impossible to identify the existence of the secure world SW from the normal world NW, which ensures the security of the processing performed in the secure world SW, the information stored in the secure world SW, etc. The secure world SW is provided with a secure storage device TS as a storage area (trusted storage) for storing data. The capacity of the secure storage device TS can be smaller than the capacity of the normal storage device US.

[0028] The vehicle-mounted ECU 100 executes a recorder process for storing the recording data segment LD (see Figure 3 ), a data providing process for providing the recorded data segments LD accumulated by the recorder process to the outside (see Figure 4 ), system monitoring processing for monitoring the status of the system (see Figure 6) etc. The vehicle-mounted ECU 100 is provided with a recorder 50 and an auditor 60 for operating in the normal world NW and a watcher 70 for operating in the secure world SW as functional units for executing the above-mentioned respective processes.

[0029] The recorder 50 is a functional unit adapted to store various types of data generated in the vehicle A in association with the blockchain BC by performing a recorder process. The recorder 50 includes functional sections, such as a data acquisition section 51, a block generation section (i.e., a block generation section, a block generator, or a block generator) 52, a data storage section 53, a hash value storage section 54, and the like.

[0030] For example, the data acquisition section 51 is electrically connected to a communication bus in the vehicle-mounted communication network. The data acquisition section 51 is capable of acquiring various types of data generated in the vehicle A, such as communication data and detection data, through the communication bus. The data acquisition section 51 extracts data predetermined to be extracted from data that has been continuously output to the communication bus through the vehicle-mounted sensor 20 and the V2X communication unit 30. In addition, the data acquisition section 51 selectively acquires the extracted data as acquired data to be stored.

[0031] exist Figure 1 and Figure 2 The block generation unit 52 shown in the figure stores the acquired data acquired by the data acquisition unit 51 as a record data segment LD. For example, the block generation unit 52 has a function of calculating a hash value by using a hash function such as SHA-256. The block generation unit 52 converts the record data segment LD into a data structure in the form of a hash chain using a hash function. In addition, the block generation unit 52 stores the data structure in a conventional storage device US. The block generation unit 52 generates a single block based on a specified number of record data segments LD or a record data segment LD with a specified capacity. The specified number or the specified capacity is predetermined. The block generation unit 52 inputs the data in a single block to the hash function to provide a hash value, and further, the block generation unit 52 introduces the hash value into the next block, thereby generating a blockchain BC in the form of a straight chain formed by a large number of blocks coupled to each other.

[0032] The block generation section 52 calculates a hash value to be stored as the main data in each block based on the specified number of recorded data segments LD or the recorded data segments LD having a specified capacity that have been acquired by the data acquisition section 51. The block generation section 52 may calculate the corresponding hash values ​​for a large number of recorded data segments LD or calculate the Merkle root for a large number of recorded data segments LD.

[0033] The data storage unit 53 stores the record data segment LD acquired by the data acquisition unit 51 in a file path specified in the regular storage device US. The data storage unit 53 stores the data of the blockchain BC generated by the block generation unit 52 in the regular storage device US. The data storage unit 53 stores the link information Lin for linking a specific block to the file path of the record data segment LD included in the specific block in the regular storage device US.

[0034] The hash value storage unit 54 is capable of updating the block hash value HvB and the block number NoB stored in the secure storage device TS by executing a predetermined command (e.g., a secure monitor call, etc.) that enables access to the secure world SW. The block hash value HvB is a hash value based on the current last block LB in the blockchain BC. The block hash value HvB is 256-bit data (character string) obtained as an output from an operation process for inputting all data in the last block LB to a hash function.

[0035] The block number NoB is a specific value assigned to the last block LB, and, assuming that the initial block is "0", is a value indicating which numbered block is the current last block LB in the blockchain BC. The block number NoB is also a value indicating the number of blocks currently coupled to the blockchain BC. Whenever the block generation unit 52 generates a new block AB and calculates its hash value, the hash value storage unit 54 updates the block hash value HvB and the block number NoB in the secure storage device TS.

[0036] In the following, we will base on Figure 3 The flowchart shown is referenced Figure 1 and Figure 2 The recorder process performed by the aforementioned recorder 50 will be described in detail. The recorder process starts based on the start of the supply of electric power to the vehicle-mounted ECU 100, and is continuously performed until the end of the supply of electric power.

[0037] In S101, it is determined whether an initial block in the blockchain BC has been generated in the conventional storage device US. If it is determined in S101 that an initial block exists, the process proceeds to S105. On the other hand, if it is determined in S101 that an initial block does not exist, the process proceeds to S102 to perform initial processing.

[0038] In S102, a hash value based on arbitrary data is calculated, and an initial block storing the hash value is set, and the process proceeds to S103. In S103, a hash value of the initial block set in S102 is calculated, and the process proceeds to S104. In S104, the hash value calculated in S103 is stored in the secure storage device TS as the initial value of the block hash value HvB, and the process proceeds to S105. In addition, in S104, "0" as an initial value is recorded at the address of the storage block number NoB in the secure storage device TS.

[0039] In S105, a process for acquiring data to be accumulated as the recording data segment LD is started, and then the process proceeds to S106. In S106, it is determined whether the acquired data to be stored has been acquired. If the data to be stored has not been acquired, the generation of data is waited for by a process for repeating the determination in S106. In addition, when the data to be stored has been acquired through the communication bus, the process proceeds from S106 to S107.

[0040] In S107, according to the command about the file path, the acquired data is stored as a recording data segment LD in a specific storage area in the conventional storage device US, and the process proceeds to S108. In S108, a hash value of the recording data segment LD stored in S107 is calculated, and the process proceeds to S109. In S107 and S108, the acquisition of the recording data segment LD and the calculation of the hash value are sequentially performed, which distributes the processing load in terms of time.

[0041] In S109, it is determined whether the number or capacity of the recorded data segments LD to be stored in the new block AB has reached the specified number or the specified capacity. If it is determined in S109 that the number or capacity of the recorded data segments LD has not reached the specified number or the specified capacity, the process returns to S106, thereby continuing to collect the recorded data segments LD. On the other hand, if it is determined in S109 that the number or capacity of the recorded data segments LD has reached the specified number or the specified capacity, the process proceeds to S110. Moreover, in S109, the time period that has passed since the generation of the previous new block AB is counted, and based on the passage of a predetermined time period (timeout), the process can proceed to S110.

[0042] In S110, by generating a set of hash values ​​based on the current last block LB and the hash values ​​of the record data segment LD calculated in S108, a new block AB is generated including at least these hash values, and the process proceeds to S111. The new block AB is stored in the conventional storage device US and coupled to the blockchain BC as a new last block BC.

[0043] In S111, link information Lin is generated and stored in the normal storage device US, and the process proceeds to S112. Link information Lin is information linking the new block AB generated in S110 to the file path defining the storage destination of the recording data segment LD having the hash value included in the new block AB.

[0044] In S112, the hash value of the new block AB is calculated, and the process proceeds to S113. In S113, the block hash value HvB in the secure storage device TS is updated using the hash value calculated in S112. In addition, in S113, the value of the block number NoB recorded in the secure storage device TS is incremented and made consistent with the block number of the new block AB. The aforementioned S106 to S113 are repeated to achieve the storage of the record data segment LD associated with the blockchain BC.

[0045] Figure 1 and Figure 2 The auditor 60 shown in FIG. 1 is adapted to execute a data providing process for providing the recorded data segments LD accumulated by the recorder 50 to the user U (see FIG. 1 ). Figure 4 ) and a functional unit for data maintenance processing related to backup and recovery of record data segments LD. Auditor 60 includes a data providing section 61 and a data checking section (ie, data verification section or data verifier) ​​62 as functional sections related to data providing processing.

[0046] The data providing unit 61 can communicate with the user interface UI (see FIG. 1 ) outside the vehicle-mounted ECU 100 in a wireless or wired manner. Figure 5 ) communication. The user interface UI is composed of a user terminal such as an HMI device, a smart phone, a tablet terminal or a personal computer incorporated in the vehicle A. The user U inputs a user operation of referencing the record data segment LD to the user interface UI. The user interface UI outputs a reference request to the data providing section 61 based on the user operation.

[0047] The data providing section 61 receives a reference request output from the user interface UI. The reference request specifies the file path of the record data segment LD that the user U wishes to reference. The data providing section 61 extracts the file path in the obtained reference request and notifies the data checking section 62 of the file path. If there is no problem in the inspection result of the data checking section 62, the data providing section 61 returns the record data segment LD specified by the file path to the user interface UI, which is the requester (i.e., the request source) of the reference request.

[0048] The data checking section 62 checks or verifies an abnormality in the specific record data segment LD (requested data) requested by the reference request (the requested data) by using the block hash value HvB stored in the secure storage device TS, the abnormality including whether there is a change, the checking or verification being triggered by receiving the reference request from the data providing section 61. The data checking section 62 specifies the block number linked to the file path specified by the reference request based on the link information Lin. The data checking section 62 checks the specified block (hereinafter referred to as the "specified block SB") and the blocks newer than the specified block SB (see Figure 2 The range of the dashed line in the middle) is used to recalculate the corresponding hash value based on the record data segment LD to check the consistency of the blockchain BC.

[0049] The data check section 62 determines the abnormality of the recorded data segment LD based on whether the recalculated hash value based on the last block LB is consistent with the block hash value HvB stored in the secure storage device TS. If the recalculated hash value of the last block LB is consistent with the block hash value HvB, the data check section 62 determines that there is no abnormality such as a change in the recorded data segment LD. If the recalculated hash value for the last block LB is inconsistent with the block hash value HvB, the data check section 62 determines that there may be an abnormality such as a change in the recorded data segment LD.

[0050] based on Figure 4 The flowchart shown is referenced Figure 1 and 2 The data providing process performed by the data providing section 61 and the data checking section 62 which have been described above will be described in further detail. The data providing process is started by the auditor 60 based on receipt of a reference request from the user interface UI.

[0051] In S131, a reference request sent from the user interface UI is received, and the processing proceeds to S132. In S132, based on the file path in the reference request obtained in S131 and the link information Lin stored in the conventional storage device US, a designated block SB linked to the file path is designated, and the processing proceeds to S133. The designated block SB is a block storing the hash value of the record data segment LD that the user U wishes to reference. In S133, for the designated block SB and the block coupled after the designated block SB, the relevant record data segment ID is read therefrom, and the hash value for the record data segment ID is recalculated, and the processing proceeds to S134.

[0052] In S134, it is determined whether the hash value for the last block LB recalculated in S133 is consistent with the block hash value HvB stored in the secure storage device TS. In S134, if it is determined that the hash value calculated at this time is consistent with the block hash value HvB, the process proceeds to S135. In S135, a normal determination is performed, indicating that all the record data segments LD used in the recalculation in S133 are not modified. In S135, based on the normal determination, the list of record data segments LD corresponding to the reference request is returned to the user interface UI, and a series of data providing processes are completed.

[0053] On the other hand, if it is determined in S134 that the two hash values ​​are inconsistent with each other, the process proceeds to S136. In S136, an abnormality determination is performed, indicating that some of the record data segments LD used in the recalculation in S133 may have been altered. In S136, based on the abnormality determination, an error notification is returned to the user interface UI, and a series of data providing processes are completed.

[0054] The user interface UI is displayed on the display based on the response from the data acquisition section 51 in S135 or S136. Figure 5 The data providing screen 80 is shown. The data providing screen 80 is composed of a block structure display area 81, a file path display area 82, a file content display area 83, and the like.

[0055] The block structure display area 81 is a display area suitable for schematically displaying the structure of the blockchain BC and various types of information stored in the blockchain BC through an image. The file path display area 82 is a display area suitable for displaying the file path included in the reference request. The file content display area 83 is a display area suitable for displaying the returned record data segment LD. If an error notification is returned to the user interface UI, an error message or the like is displayed on the file content display area 83.

[0056] like Figure 1 As shown, the auditor 60 includes a backup sending unit 63 and a data recovery unit (i.e., a data recovery unit or a data restorer) 64 as functional units related to data maintenance processing. In cooperation with the DCM 40, the backup sending unit 63 and the data recovery unit 64 can share the record data segment LD with the backup server BS.

[0057] The backup sending section 63 detects a new block AB generated by the block generating section 52. If a new block AB is generated by the block generating section 52, the backup sending section 63 sends backup data of a large number of record data segments LD having a hash value stored in the new block AB to the external backup server BS. The backup server BS stores the backup data sent from the backup sending section 63 in a storage medium (e.g., a hard disk drive) having a large capacity in a manner of associating it with the ID information on the vehicle-mounted ECU 100.

[0058] When the DCM 40 is prohibited from communicating, the backup transmission unit 63 suppresses transmission of the recording data segment LD to the backup server BS. In this case, when the DCM 40 has recovered to a state capable of communication, the backup transmission unit 63 restarts transmission of the backup data that has not yet been transmitted.

[0059] The data recovery section 64 detects the abnormality determination performed by the data check section 62. If an abnormality such as alteration or defect occurs in the recorded data segment LD and the data check section 62 performs abnormality determination on the recorded data segment LD, the data recovery section 64 recovers the recorded data segment LD using the backup data stored in the backup server BS. Figure 2 ) and multiple record data segments LD of hash values ​​in each block after the designated block SB, the data recovery unit 64 requests the backup server BS to send the backup data. Assuming that the backup data received from the backup server BS is a normal record data segment LD, the data recovery unit 64 overwrites the record data segment LD designated by the file path with the corresponding backup data. Moreover, the data recovery unit 64 can obtain all the backup data from the backup server SB and can perform a process for updating all the record data segments LD.

[0060] The observer 70 operates in the secure world SW, thereby preventing tampering from outside the vehicle-mounted ECU 100 and from the normal world NW. The observer 70 is a functional unit adapted to monitor the conditions of the recorder 50 and the auditor 60 in the normal world NW at regular time intervals from the secure world SW.

[0061] The observer 70 starts the system monitoring process at a predefined period (see Figure 6 ) to perform monitoring at regular time intervals. The observer 70 acquires from the conventional world NW an executable file for the recorder 50 required for performing the recorder process and an executable file for the auditor 60 required for performing the data provision process and the data maintenance process (see Figure 6 (S151 in ).

[0062] In other words, the executable file of the recorder 50 is an executable file related to the data acquisition unit 51, the block generation unit 52, the data storage unit 53, and the hash value storage unit 54. Similarly, in other words, the executable file of the auditor 60 is an executable file related to the data provision unit 61, the data inspection unit 62, the backup transmission unit 63, and the data recovery unit 64. The observer 70 comprehensively acquires the entirety of each executable file. For example, the executable file includes a binary file. The executable file may also include a compiler, a linker, a library, etc.

[0063] The viewer 70 inputs the respective executable files to the hash function in a predefined order to calculate a hash value for the recorder 50 and a hash value for the auditor 60 (refer to S152).

[0064] The secure storage device TS stores the hash value based on the initial executable file that is guaranteed not to be modified as the monitoring hash value. More specifically, the recorder hash value HvL based on the normal executable file of the recorder 50 and the auditor hash value HvA based on the normal executable file of the auditor 60 are stored in the secure storage device TS as monitoring hash values. The recorder hash value HvL and the auditor hash value HvA are stored in the secure storage device TS, thereby preventing them from being modified by being accessed from the outside and the conventional world NW.

[0065] The observer 70 determines whether the hash value of the executable file based on the recorder 50, which has been acquired through the system monitoring process at this time, is consistent with the recorder hash value HvL stored in the secure storage device TS (refer to S153). Similarly, the observer 70 determines whether the hash value of the executable file based on the auditor 60, which has been acquired at this time, is consistent with the auditor hash value HvA stored in the secure storage device TS (refer to S153).

[0066] If the observer 70 determines that the corresponding hash values ​​calculated for the recorder 50 and the auditor 60 at this time are consistent with the corresponding monitoring hash values ​​HvL and HvA, the observer 70 performs a normal determination indicating that the corresponding executable file has not been altered. (Refer to S154). On the other hand, if the observer 70 determines that at least one of the corresponding hash values ​​calculated at this time is inconsistent with the corresponding monitoring hash values ​​HvL and HvA, the observer 70 performs an abnormal determination indicating that the executable file may have been altered (Refer to S155). In this case, an error notification is issued to the user U, and a series of system monitoring processes are completed.

[0067] In the first embodiment described above, the hash value of the new block AB newly coupled to the blockchain BC is stored as a block hash value HvB in the secure storage device TS, in which access from the normal world NW is restricted. This makes it possible to detect changes in the recorded data segment LD obtained in the vehicle A, etc. by using a comparison of the block hash value HvB protected by the secure world SW.

[0068] More specifically, the hash values ​​of the various record data segments LD are introduced in the blockchain BC, so even if only one record data segment LD is changed, this causes the final block hash value HvB to be changed. Therefore, if only the block hash value HvB is protected, changes in all record data segments LD can be detected based on comparison with the block hash value HvB.

[0069] This enables storage of the recorded data segment LD acquired in the vehicle A while ensuring the reliability thereof.

[0070] In addition, in the first embodiment, the link information Lin related to the link of the record data segment LD to the blockchain BC is stored in the conventional storage device US. Therefore, in response to a reference request from the user interface UI, the specified block SB related to the requested record data segment LD can be immediately specified based on the link information Lin. The aforementioned structure makes it possible to easily ensure the availability for the user U who references the record data segment LD.

[0071] In the first embodiment, if a reference request for a specific recorded data segment LD is received, the data check section 62 checks whether there is a change in the requested recorded data segment LD. In order to check for changes, the block hash value HvB stored in the secure storage device TS is used. As described above, since a check on the possibility of a change in the recorded data segment LD is performed each time a reference request is received, the reliability of the recorded data segment LD provided to the user interface UI can be appropriately ensured.

[0072] In the first embodiment, the data check section 62 recalculates the hash values ​​of the designated block SB and the blocks coupled after the designated block SB. If the hash value of the last block LB is consistent with the block hash value HvB in the secure storage device TS, the data check section 62 determines that there is no change therein. Through this processing, it is possible to accurately check whether there is a change in a large number of recorded data segments LD while reducing the capacity of the data stored in the secure storage device TS.

[0073] In addition, in the first embodiment, the recorder 50 and the auditor 60 operate in the normal world NW. This can reduce resource consumption of the secure world SW.

[0074] In the first embodiment, the observer 70 operates in the secure world SW and determines whether there is a modification in the corresponding executable files of the recorder 50 and the auditor 60. With the aforementioned structure, even if the recorder 50 and the auditor 60 operate in the normal world NW, their normal operations are guaranteed by the observer 70 operating in the secure world SW. With the above structure, the resources of the vehicle-mounted ECU 100 can be effectively utilized while ensuring the reliability of the recording data segment LD.

[0075] In the first embodiment, the recorder hash value HvL and the auditor hash value HvA of the corresponding normal executable file based on the recorder 50 and the auditor 60 are stored in the secure world SW. If the hash value based on the corresponding current executable file is consistent with the corresponding monitoring hash values ​​HvL and HvA, the observer 70 determines that the executable file has not been modified. Through this process, it is possible to accurately check whether there is a modification in the corresponding executable file that tends to have a larger capacity while reducing the capacity of the data stored in the secure storage device TS.

[0076] In addition, in the first embodiment, the recorded data segment LD is transmitted to the backup server BS provided outside the vehicle-mounted ECU 100, and is stored in the backup server BS as backup data. If an abnormality occurs in the recorded data segment LD stored in the vehicle-mounted ECU 100, the recorded data segment LD in the vehicle-mounted ECU 100 is restored using the backup data stored in the backup server BS. As described above, since a means for restoration by backup is ensured, even if the recorded data segment LD is stored in the conventional storage device US, its reliability can be ensured.

[0077] In the first embodiment, the vehicle A corresponds to the "mobile body", the backup server BS corresponds to the "storage device", and the user interface UI corresponds to the "requester". The conventional storage device US corresponds to the "storage area in the conventional world", the secure storage device TS corresponds to the "storage area in the secure world", and the recorder hash value HvL and the block hash value HvB each correspond to the "monitoring hash value". The card reader 15 corresponds to the "storage connection section", the data storage section 53 corresponds to the "conventional storage processing section", the hash value storage section 54 corresponds to the "secure storage processing section", and the viewer 70 corresponds to the "file monitoring section". The vehicle-mounted ECU 100 corresponds to the "data storage device".

[0078] Second embodiment

[0079] Figure 7A second embodiment of the present disclosure is shown, which is a modified example of the first embodiment. In the second embodiment, the vehicle-mounted ECU 100 includes a control circuit provided with a card reader 15. The card reader 15 is provided with a slot portion into which a memory card MC is inserted. The memory card MC is a removable medium that can be attached to and detached from the card reader 15. The memory card 15 is electrically connected to the card reader 15 and serves as an auxiliary storage device of the control circuit. The card reader 15 is adapted to write data into and read data from the memory card MC.

[0080] The recorder 50 is also provided with an external medium storage section 55. The external medium storage section 55 is adapted to store the recording data segment LD in a memory card MC connected to the card reader 15. The external medium storage section 55 utilizes a storage area in the memory card MC as a part of the conventional storage device US. When the conventional storage device US is extended by the memory card MC, the recording data segment LD may be stored in both the storage section 13 and the memory card MC, or only in the memory card MC.

[0081] The data check unit 62 in the auditor 60 can also use the block hash value HvB to check whether there is an abnormality, such as a change in the record data segment LD stored in the memory card MC. As an example, the record data segment LD stored in the memory card MC is read by the data check unit 62 triggered by the connection of the memory card MC with the card reader 15. Based on the record data segment LD read therefrom, the data check unit 62 recalculates the hash value in the order that conforms to the blockchain BC, and obtains the hash value of the last block LB.

[0082] If the hash value of the recalculated last block LB is consistent with the block hash value HvB in the secure storage device TS, the data check section 62 determines that the recorded data segment LD in the memory card MC is normal. On the other hand, if the hash value of the recalculated last block LB is inconsistent with the block hash value HvB in the secure storage device TS, the data check section 62 performs abnormality determination indicating that the recorded data segment LD in the memory card MC may have been altered.

[0083] In the second embodiment described above, similarly, since the block hash value HvB stored in the secure storage device TS is used, the recording data segment LD can be stored while ensuring the reliability of the recording data segment LD.

[0084] In addition, in the second embodiment, the recorded data segment LD can be stored in the memory card MC, and the data check section 62 can use the block hash value HvB to check whether there is a change in the recorded data segment LD stored in the memory card MC. With the above structure, the storage area for storing the recorded data segment LD can be expanded while preventing the reliability of the recorded data segment LD from being reduced.

[0085] In the second embodiment, the memory card MC corresponds to an "external storage device", the card reader 15 corresponds to a "storage connecting section", and the external medium storage section 55 corresponds to an "external area storage section".

[0086] Other Implementations

[0087] Although the embodiments of the present disclosure have been described above, the present disclosure should not be construed as being limited to the aforementioned embodiments. The present disclosure can be applied to various embodiments and various combinations thereof without departing from the gist of the present disclosure.

[0088] In the aforementioned embodiment, the auditor 60 operates in the normal world NW. However, in the first modified example of the aforementioned embodiment, the auditor 60 operates in the secure world SW. If there is room in the operating resources of the secure world SW, as described above, the auditor 60 may also be placed in the secure world SW as in the first modified example. In this case, the function of monitoring the auditor 60 of the observer 70 may be removed.

[0089] In the second modified example of the aforementioned embodiment, the function of sending the backup data to the backup server BS is removed. The vehicle-mounted ECU 100 having such a configuration can also be incorporated into a vehicle A that is not a networked car. The vehicle-mounted ECU 100 in the second modified example is capable of storing the backup data in the memory card MC. If an abnormality occurs in the recorded data segment LD in the normal world NW constituted by the storage unit 13, the vehicle-mounted ECU 100 can restore the recorded data segment LD using the backup in the memory card MC.

[0090] In the third modified example of the aforementioned embodiment, only a portion of the acquired data is stored in a state linked to the blockchain BC. As in the third modified example, the record data segments LD to be stored in a protected state and the record data segments LD to be stored in an unprotected state may also be selected according to the importance of the acquired data. For example, in order to reduce storage capacity, some record data segments LD may also be deleted in order starting from the oldest data. In addition, in order to reduce data capacity, authorized users may be allowed to delete data.

[0091] In the fourth modified example of the aforementioned second embodiment, a storage device connected to the vehicle communication network is used as an external storage device instead of the memory card MC. In the fifth modified example of the above embodiment, a storage unit in a user terminal paired with the vehicle-mounted ECU 100 is used as an external storage device instead of the memory card MC. As in the fourth and fifth modified examples described above, the external storage device is not limited to the memory card MC. The data check section 62 is capable of performing a check process using the block hash value HvB for the recorded data segment LD stored in various types of external media.

[0092] In the sixth modified example of the aforementioned embodiment, the hash value of the recording data segment LD is calculated at different timings in the recorder process. More specifically, in the recorder process in the sixth modified example, if it is determined that the number or capacity of the recording data segments LD has reached the specified number or the specified capacity, the corresponding hash values ​​of all the recording data segments LD to be introduced into a single block are calculated. As described above, after all the recording data segments LD are collected, the process for calculating the hash values ​​of these data segments can be immediately executed.

[0093] The data that can be stored by the data storage device is not limited to text data. Depending on the capacity of the conventional storage device US, for example, sound data, image data, picture data, etc. can also be stored therein. The data stored in the corresponding block in the blockchain BC can also be changed as needed.

[0094] In the aforementioned embodiment, the hash function used in the vehicle-mounted ECU 100 is a cryptographic hash function. Such a cryptographic hash function has the following characteristics. That is, such a cryptographic hash function does not output the same hash value in response to different inputs thereto. In addition, such a cryptographic hash function makes it substantially impossible to estimate its input based on the hash value output therefrom. Depending on the required output length (number of bits), corresponding algorithms of SHA-1, SHA-2, and SHA-3 may also be employed instead of the aforementioned SHA-256, which is one of the SHA-2s.

[0095] The vehicle A incorporating the on-vehicle ECU 100 may be an owner's car that is personally owned by a certain owner and intended to be used by the owner, etc. By applying the present disclosure to such an owner's car, the recorded data segments LD indicating the driving history of the user accumulated in a state prevented from being impersonated are very valuable to a service provider that determines insurance premiums based on, for example, driving conditions.

[0096] The vehicle incorporating the on-vehicle ECU 100 may also be a vehicle as a taxi, a vehicle as a passenger taxi, a vehicle for ride-sharing, a freight vehicle, a bus, etc. The on-vehicle ECU 100 may also be incorporated in an unmanned vehicle for use in mobile services. As mobile services become more popular in the future, it is expected that the importance of the recorded data segment LD accumulated in the on-vehicle ECU 100 will be further increased.

[0097] The ECU having the function of a data storage device may also be incorporated in a mobile body other than a vehicle. For example, such an ECU having the function of a data storage device may be incorporated in a heavy machine used in a workplace, a driving amusement device placed in an amusement facility, a railway vehicle, a tram, an airplane, etc.

[0098] In the aforementioned embodiment, the corresponding functions provided by the vehicle-mounted ECU 100 can also be provided by software and hardware for executing the software, only software, only hardware, and complex combinations thereof. In the case where these functions are provided by electronic circuits as hardware, the corresponding functions can also be provided by analog circuits or digital circuits including a large number of logic circuits.

[0099] In the aforementioned embodiments, the corresponding processor may include at least one operating core, such as a CPU (central processing unit) or a GPU (graphics processing unit). The processor may further include an IP core, etc., which includes an FPGA (field programmable gate array) and other dedicated functions.

[0100] The configuration of the storage medium for storing the corresponding program related to the data storage method according to the present disclosure can also be changed as needed, and the storage medium is used as the storage unit according to the aforementioned embodiment. For example, as in the aforementioned second embodiment, the storage medium is not limited to the structure provided on the circuit board, and the storage medium can also be provided in the form of a memory card or the like that is suitable for being inserted into the slot portion and electrically connected to the bus in the computer. The storage medium can also be composed of an optical disk that forms the source of the program to be copied into the computer, a hard disk drive therefor, etc.

[0101] The controller and method described in the present disclosure can be implemented by a special-purpose computer generated by configuring a memory and a processor, and the processor is programmed to perform one or more specific functions implemented in a computer program. Alternatively, the controller and method described in the present disclosure can be implemented by a special-purpose computer generated by configuring a processor provided by one or more special-purpose hardware logic circuits. Alternatively, the controller and method described in the present disclosure can be implemented by one or more special-purpose computers generated by configuring a memory and a processor programmed to perform one or more specific functions and a combination of processors provided by one or more hardware logic circuits. The computer program can be stored in a tangible non-transient computer-readable medium as an instruction executed by a computer.

[0102] Note that the flowcharts or process of the flowcharts in the present application include parts (also referred to as steps), each part, for example, is represented as S101. In addition, each part can be divided into several sub-parts, and several parts can be combined into a single part. In addition, each part configured in this way can also be referred to as a device, module or means.

[0103] Although the present disclosure has been described with reference to the embodiments of the present disclosure, it should be understood that the present disclosure is not limited to the embodiments and configurations. The present disclosure is intended to cover various modifications and equivalent arrangements. In addition, however, various combinations and configurations, other combinations and configurations including more, less or only a single element are also within the spirit and scope of the present disclosure.

Claims

1. A data storage device in a mobile body (A), the data storage device being used to define a normal world (NW) and a secure world (SW) whose access from the normal world (NW) is restricted, and being used to store data acquired in the mobile body using a blockchain (BC), the data storage device comprising: A conventional storage processing unit (53) configured to store the acquired data in a storage area (US) of the conventional world; a block generator (52) configured to generate a new block (AB), the new block (AB) comprising a hash value based on a last block (LB) last coupled to the blockchain and a hash value based on the acquired data; as well as A secure storage processing unit (54) is configured to store a hash value based on the new block as a block hash value (HvB) in a storage area (TS) of the secure world.

2. The data storage device according to claim 1, wherein: The regular storage processing unit is configured to store link information (Lin) related to a link between the acquired data and the blockchain in a storage area of ​​the regular world.

3. The data storage device according to claim 1, further comprising: A data verifier (62) is configured to receive a reference request for specific acquired data and determine whether the specific acquired data has been tampered with based on the block hash value, and the specific acquired data is provided as requested data to a request source (U) of the reference request.

4. The data storage device according to claim 3, wherein: The data validator is configured to: specifying a specific block (SB) of data linked to the request (S132); recalculating one or more hash values ​​related to the specific block and one or more blocks coupled after the specific block (S133); as well as When the recalculated hash value of the current last block is equal to the block hash value of the secure world, it is determined that the specific acquired data has not been tampered with (S135).

5. The data storage device according to claim 3, wherein: The data validator operates in the conventional world.

6. The data storage device according to claim 3, further comprising: An external area storage device (55) configured to store the acquired data in an external storage device (MC) connected to the memory connector (15), wherein: The data verifier is configured to verify whether the acquired data stored in the external storage device via the external area storage device is tampered with based on the block hash value.

7. The data storage device according to claim 3, further comprising: A file monitor (70) is configured to operate in the secure world and determine whether an executable file associated with the data validator has been tampered with.

8. The data storage device according to claim 7, wherein: The file monitor is configured to determine whether an executable file associated with at least one of the block generator, the conventional storage processing unit, and the secure storage processing unit has been tampered with.

9. The data storage device according to claim 8, wherein: The storage area of ​​the secure world stores a hash value based on a normal executable file as a monitoring hash value (HvL, HvA); and The file monitor is configured to determine that the executable file has not been tampered with when a hash value based on the current executable file is equal to the monitoring hash value.

10. The data storage device according to any one of claims 1 to 9, further comprising: a backup transmitter (63) configured to transmit backup data of the acquired data to an external storage (BS); as well as A data restorer (64) is configured to restore the acquired data using the backup data stored in the external memory when an abnormality occurs in the acquired data.

11. A non-transitory tangible computer-readable storage medium, comprising instructions executed by a computer, the instructions comprising a method in a mobile body (A), the method for defining a normal world (NW) and a secure world (SW) whose access from the normal world (NW) is restricted, and for storing data acquired in the mobile body using a blockchain (BC), the instructions causing at least one processor (11) to perform the following processing: storing the acquired data in the storage area (US) of the conventional world (S107); generating a new block (AB) (S110), the new block (AB) including a hash value based on the last block (LB) last coupled to the blockchain and a hash value based on the acquired data; and The hash value based on the new block is stored as a block hash value (HvB) in the storage area (TS) of the secure world (S113).

Images